1. Why test?
1.1. WHY TEST DRIVEN DEVELOPMENT
1.1.1. The Usual Way
1.1.1.1. One way is to manually run your program after writing it. You write a new feature, open a browser, click around to see that it works, then continue adding more features.
1.1.2. The Issue
1.1.2.1. You write some new code, but it unexpectedly breaks old features and you might not even know it. This is called a regression.
1.1.3. The Proposal
1.1.3.1. A better way is to have the computer check our work. We write software to auto- mate our lives, so why not write programs to test our code as well? Automated tests are scripts that output whether or not your code works as intended
1.1.3.1.1. When applications grow without a solid test suite, teams are often discouraged by frequent bugs quietly sneaking into their code. The common solution is to hire dedicated testers; a Quality Assurance (QA) team. This is an expensive mistake. As your application grows, now you have to scale the number of hands on deck, who will never be as effective as automated tests at catching regressions. QA increases the time to implement features, as developers must communicate back and forth with another human. Compared to a test suite, this is costly.
1.1.3.1.2. At the end of the day, testing is about saving time and money
1.1.3.1.3. Consider automated tests an investment. At first, you will add time by writing tests you would otherwise not be writing. However, most real applications don’t stay the same; they grow. An effective test suite will keep your code honest, and save you time debugging over the lifetime of the project. The time savings grow as the project progresses.
1.1.3.2. confidence to make changes to big chunks of the code
1.1.3.2.1. if you wrote a test for every feature then you know every feature works
1.1.3.3. Testing first also puts positive design pressure on code, as it influences code to be written to solve the problem at hand (and not to tackle other future problems that may be out of scope, but are tempting to try to solve now). In this way, TDD acts as a workflow hack, promoting incremental, steady progress toward delivery.
1.1.3.4. But there's another benefit: tests are automated, living documentation! Comments have a problem in that they may be outdated, which makes them worse than no comments at all if they say the wrong thing and inspire false confidence.
2. Section 1
2.1. Why test?
2.1.1. WHY TEST DRIVEN DEVELOPMENT
2.1.1.1. The Usual Way
2.1.1.1.1. One way is to manually run your program after writing it. You write a new feature, open a browser, click around to see that it works, then continue adding more features.
2.1.1.2. The Issue
2.1.1.2.1. You write some new code, but it unexpectedly breaks old features and you might not even know it. This is called a regression.
2.1.1.3. The Proposal
2.1.1.3.1. A better way is to have the computer check our work. We write software to auto- mate our lives, so why not write programs to test our code as well? Automated tests are scripts that output whether or not your code works as intended
2.1.1.3.2. confidence to make changes to big chunks of the code
2.1.1.3.3. Testing first also puts positive design pressure on code, as it influences code to be written to solve the problem at hand (and not to tackle other future problems that may be out of scope, but are tempting to try to solve now). In this way, TDD acts as a workflow hack, promoting incremental, steady progress toward delivery.
2.1.1.3.4. But there's another benefit: tests are automated, living documentation! Comments have a problem in that they may be outdated, which makes them worse than no comments at all if they say the wrong thing and inspire false confidence.
2.2. What is testing
2.2.1. WHAT IS TEST DRIVEN DEVELOPMENT
2.2.1.1. Test-Driven Development is a development technique where you write a failing test and then create code to make that test pass.
2.2.1.1.1. This process is sometimes called a red-green-refactor cycle with the failing tests being the "red" state, passing tests being the "green" state, and the refactoring step occurring after tests pass, where code can be confidently improved.
2.2.1.2. The practice of Test-Driven Development over time generates a growing suite of tests that can serve as protection against a regression (the breaking of a previously working feature)
2.2.1.2.1. A test suite is the collection of tests that ensure that your system works.
2.2.1.2.2. A test suite will be comprised of many different kinds of tests, varying in scope and subject matter. Some tests will be high level, testing an entire feature and walking through your application
2.3. How Does It Work?
2.3.1. HOW DOES TEST DRIVEN DEVELOPMENT WORK
2.3.1.1. write a test - make it past - write a test-make it past
2.3.1.1.1. distinct from test less approach. Where you save testing for the end if you have time which you never do
2.3.1.2. TDD Process
2.3.1.2.1. Write the test
2.3.1.2.2. Fail the test
2.3.1.2.3. Pass the test
2.4. 'I'VE HEARD TESTING IS HARD'
2.4.1. maybe a little, but it's important. And it saves time in the long run and allows you to confidently maintain and change your code base.
2.4.2. So it is more work to do test driven development, but it's important and worth it work. And if you have a full suite of regression tests, you can be confident in contiuing to change your code base
2.4.3. There are perceptions that testing is time-consuming, and reduces efficiency, as the writing and maintenance of testing occupies time that could be spent writing new features.
2.4.4. While testing does require time to do well, as an code base gets larger and larger, the benefits of being able to quickly and accurately validate that the functionality does what is intended grow.
2.5. Setup environment
2.6. When you don't need to test
2.7. Setup testing environment on your computer
3. Section 2
3.1. TDD HIGH LEVEL FLOW
3.1.1. writing tests
3.1.1.1. then writing code
3.1.1.1.1. then writing tests
3.1.2. as you get used to tdd you may be thrown off by the errors you get back. But in TDD the errors are good, you want to create the erros and then write the code to fix them and then write another test to cause an error. To write the code to fix that.
3.2. Manual testing
3.3. What's a good test
3.3.1. Characteristics of an Effective Test Suite
3.3.1.1. Fast
3.3.1.1.1. The faster your tests are, the more often you can run them. Ideally, you can run your tests after every change you make to your codebase. Tests give you the feed- back you need to change your code. The faster they are the faster you can work and the more you can get done.
3.3.1.1.2. When you run slow tests, you have to wait for them to complete. If they are slow enough, you may even decide to take a coffee break or check Twitter. This quickly becomes a costly exercise. Even worse, you may decide that running tests is such an inconvenience that you stop running your tests altogether.
3.3.1.1.3. having fast tests is important, as you can see we run them a lot!
3.3.1.2. Complete
3.3.1.3. Reliable
3.3.1.4. Isolated
3.3.1.4.1. Tests can run in isolation. They set themselves up, and clean up after themselves. Tests need to set themselves up so that you can run tests individually. When work- ing on a portion of code, you don’t want to have to waste time running the entire suite just to see output from a single test. Tests that don’t clean up after them- selves may leave data or global state which can lead to failures in other tests when run as an entire suite.
3.3.1.5. Maintainable
3.3.1.6. Expressive
3.3.1.6.1. Tests are a powerful form of documentation because they are always kept up to date. Thus, they should be easy enough to read so they can serve as said doc- umentation. During the refactor phase of your TDD cycle, be sure you remove duplication and abstract useful constructs to keep your test code tidy.
3.3.2. ANOTHER BENEFIT OF TDD TESTING
3.3.2.1. But there's another benefit: tests are automated, living documentation!
3.3.2.2. Executable Documentation
3.3.2.3. Comments have a problem in that they may be outdated, which makes them worse than no comments at all if they say the wrong thing and inspire false confidence.
3.4. Testing with Mocha
3.5. When to write a test
3.6. What is TDD + red-green-refactor
3.6.1. TESTS CAN TELL A STORY : FOUR PHASES OF TESTING
3.6.1.1. Four Phase Test
3.6.1.1.1. Setup During setup, we create any objects that your test depends on
3.6.1.1.2. Exercise During exercise, we execute the functionality we are testing
3.6.1.1.3. Verify During verify, we check our expectations against the result of the exercise phase
3.6.1.1.4. Teardown During teardown, we clean-up after ourselves. This may involve resetting the database to it’s pre-test state or resetting any modified global state. This is usually handled by our test framework. Four phase testing is more prominently used with model and unit tests, however it isstillusefulforouracceptancetests. Thisisespeciallytrueforsimpletestslikethe two we’ve demonstrated, however some acceptance tests may be large enough to warrant even more grouping. It’s best to use your discretion and group things into logical sections to make code easier to read.
3.6.1.2. These stories have four acts, which in test parlance are "phases":
3.6.1.2.1. Setup - get the conditions correct for the test
3.6.1.2.2. Exercise - perform the thing that you're testing
3.6.1.2.3. Verification - verify that the exercise did what you expected
3.6.1.2.4. Teardown - undo any conditions that shouldn't persist post-test
3.6.1.3. TEST PHASES IN ACTION
3.6.1.3.1. Let's examine the test phases in an example.
3.7. TDD with Mocha
3.8. Integration tests
3.9. Unit + integration test of simple HTML/CSS/JS application
3.9.1. SIMPLE EXAMPLE-CALCULATOR
3.9.1.1. demo: simple calculator
3.9.1.1.1. A number of langauges to write tests in
3.9.1.1.2. Factorial Test
4. Section Three: Key Terms
4.1. Test Driven Development
4.2. Outside In Development
4.2.1. Working outside-in is desirable when you have a good understanding of the prob- lem, and have a rough understanding of how the interface and code will work ahead of time. Because you are starting from a high level, your code will not work until the very end, however your first test will guide your design all the way to completion. You have to trust that your test will bring you there successfully.
4.3. Test Pyramid
4.3.1. TestPyramid For Agile
4.3.1.1. The various test types we are about to look at fall along a spectrum.
4.3.1.1.1. Unit Tests
4.3.1.1.2. Many test types are neither purely unit nor integration tests. Instead, they lie somewhere in between, testing several components together but not the full sys- tem.
4.3.1.1.3. Integration Tests
4.3.1.1.4. Untitled
4.3.1.1.5. Acceptance Test
4.4. Section 3
4.4.1. Testing pyramid
4.4.2. Outside-in
4.4.3. Testing: Features
4.4.4. Testing: Server
4.4.5. Testing: Database
4.4.6. Refactor a green suite
4.4.7. Outside-in with TDD (Lesson, quiz, project)
4.4.8. How testing integrates into a real development process
4.4.9. Build full-stack testing suite without React