When should I write the different kinds of tests in TDD?

1
votes

There are different kinds of tests: unit, integration, functional, and acceptance. So if I'm doing proper test-driven development, when do I write each kind of test?

I'm thinking that in typical TDD, the unit tests are the kind of tests that precede the writing of code. The typical workflow I see is:

  1. Write failing unit test
  2. Run test to verify that it fails
  3. Write simplest passing function/method
  4. Run test to verify that it passes
  5. Refactor code

Soooo...where do the integration, functional, and acceptance tests come in? Do you write them after the code? Or do you write them along with the unit test at the very beginning?

Also, as an additional question, I often hear about this "100% code coverage" idea. It's easy to see how this would apply to unit testing--just have one test for every method. But should you aim to have 100% code coverage for each kind of test? For example, should unit tests cover 100% of my code AND functional tests cover 100% of my code (albeit from a more broad perspective)?

2
unit-testingtestingtddintegration-testingfunctional-testing

2 Answers

1
votes

While it tends to fit more naturally with lower level tests, TDD is really a mindset that can be applied at any (or all) levels. You could write a failing acceptance test, then write corresponding failing integration tests, break them down into failing unit tests and then "green up" your way back to the original acceptance test as you make each test in the chain pass.

An article that illustrates this : ATDD From the Trenches

Regarding code coverage, in my experience you get most of it from unit tests and/or integration tests, depending on the degree of isolation you like in your testing style. Anyway, I see them as complementary, you shouldn't look for 100% coverage in each test category. Higher-level (system, end to end, acceptance...) tests on the other hand will typically bust configuration/environment problems, which generally doesn't have an impact on code coverage.

0
votes

I typically first write an external test first that will drive the development of the feature. This approach is part of the London School of TDD.

As highlighted in the above article by Jason Gorman, The London school's definitive text is Growing Object Oriented Software Guided By Tests by Steve Freeman and Nat Pryce.