1. TDD HIGH LEVEL FLOW
1.1. writing tests
1.1.1. then writing code
1.1.1.1. then writing tests
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.
2. What is testing
2.1. WHAT IS TEST DRIVEN DEVELOPMENT
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.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.1.1.1.1. Red, Green, Refactor is a series of steps that lead you through developing a given feature or fixing a bug:
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.1.2.1. A test suite is the collection of tests that ensure that your system works.
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
3. How Does It Work?
3.1. HOW DOES TEST DRIVEN DEVELOPMENT WORK
3.1.1. write a test - make it past - write a test-make it past
3.1.1.1. distinct from test less approach. Where you save testing for the end if you have time which you never do
3.1.2. TDD Process
3.1.2.1. Write the test
3.1.2.1.1. start with a test describing the functionality we’d like to see.
3.1.2.2. Fail the test
3.1.2.2.1. it is imperative that you only write code in response to the test that would have failed.
3.1.2.3. Pass the test
3.1.2.3.1. To do this, we’ll read the error messages one at a time and write only enough code to make the current error message pass.
4. What is TDD + red-green-refactor
4.1. TESTS CAN TELL A STORY : FOUR PHASES OF TESTING
4.1.1. Four Phase Test
4.1.1.1. Setup During setup, we create any objects that your test depends on
4.1.1.2. Exercise During exercise, we execute the functionality we are testing
4.1.1.3. Verify During verify, we check our expectations against the result of the exercise phase
4.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.
4.1.2. These stories have four acts, which in test parlance are "phases":
4.1.2.1. Setup - get the conditions correct for the test
4.1.2.1.1. create objects
4.1.2.2. Exercise - perform the thing that you're testing
4.1.2.2.1. run the behavior that we want them to have
4.1.2.3. Verification - verify that the exercise did what you expected
4.1.2.3.1. check that what we wanted to happen-happened
4.1.2.4. Teardown - undo any conditions that shouldn't persist post-test
4.1.2.4.1. Undo any side effects that we didn't want to happen.
4.1.3. TEST PHASES IN ACTION
4.1.3.1. Let's examine the test phases in an example.
4.1.3.1.1. (In this test the teardown phase isn't necessary.)
4.1.3.1.2. This test breaks its phases into distinct, easily identifiable parts. (You don't need the comments, those are here for emphasis.) It's often a good idea to add a line break between phases to help a developer (who might be you in the future!) to discern the borders of your tests' phases.
4.1.3.1.3. The test is also written to be explicit about what's being tested. A new Membership is not an admin membership by default, but Harry is setting admin: false in the setup phase to help communicate intent about what the test is doing.
5. What's a good test
5.1. Characteristics of an Effective Test Suite
5.1.1. Fast
5.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.
5.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.
5.1.1.3. having fast tests is important, as you can see we run them a lot!
5.1.2. Complete
5.1.3. Reliable
5.1.4. Isolated
5.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.
5.1.5. Maintainable
5.1.6. Expressive
5.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.
5.2. ANOTHER BENEFIT OF TDD TESTING
5.2.1. But there's another benefit: tests are automated, living documentation!
5.2.2. Executable Documentation
5.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.