Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Most (all?) TDD resources show you how the cycle goes:

  • Write Test
  • Check Test
  • Write Production Code
  • Check Test
  • Clean up Production Code
  • Check test

They also - to me - seem to imply that all code is covered by tests.

However, reading posts like Writing Great Unit Tests: Best and Worst Practices (for example, linked to here) it's said that

TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests

To fill in some more context:

At the other end of the scale, integration tests contain no knowledge about how your codebase is broken down into units, but instead make statements about how the whole system behaves towards an external user.

This makes perfect sense to me. However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it probably falls into "Dirty Hybris":

Anywhere in between, it’s unclear what assumptions you’re making and what you’re trying to prove. Refactoring might break these tests, or it might not, regardless of whether the end-user experience still works

So to sum up:

  • I easily see the value of Unit Tests with TDD
  • Some code is needed to wire the units together
  • This code will be complex and integration testing will/may not be enough.
  • TDD resources on the net seem to imply 100% code/test coverage, yet
  • looking at TDD with True Unit Tests will leave some code untested

Edit: wikipedia says:

Integration testing takes as its input modules that have been unit tested

but somehow I feel there's still quite a bit of wiring code missing from the picture. (except if "module" means "class or function" because that is what's unit tested in isolation)


Insights?

share|improve this question
2  
Perhaps the wikipedia quote would be clearer if it was formulated like this: Integration testing takes as its input units that have been unit tested. Yes, module can be interpreted as meaning class or function in this case. –  Treb Oct 4 '11 at 15:06
    
You may have forgotten that you can also unit-test the glue that wires units together - a unit doesn't have to live in a vacuum to be tested; wiring it up against mock classes or simulating whatever ecosystem they need is perfectly fine, as long as the tests test what they should test. –  tdammers Oct 4 '11 at 15:31

1 Answer 1

up vote 7 down vote accepted

However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it probably falls into "Dirty Hybris":

Your assumption is faulty because you are neglecting a layer of testing - acceptance testing.

Your unit tests cover individual units - the classes and methods that compose them. This enables you to test methods and classes in isolation to ensure that they are behaving as expected. Above this lies your integration tests, which tests the collaboration between classes and ensures that larger modules (packages and even inter-package collaboration) work as expected. Finally, your acceptance tests are used to verify and validate your entire system, as assembled, against the user requirements.

Assuming that you have the appropriate unit and integration tests that correspond to requirements and well-defined acceptance criteria and acceptance test plans, then everything in your system is tested. Other aspects of testing - smoke tests, regression tests, and so forth, are simply an appropriate subsampling of the unit, integration, and acceptance tests.

TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests

That particular quote is also missing something. As I was taught, TDD isn't just about unit tests, but developing all tests first. That includes not only unit tests, but the necessary acceptance and integration tests as well.

share|improve this answer
    
You say: "unit tests ... above this lies your integration tests" -- however, the post I link to says "Integration Tests: Automate the entire system" ... this doesn't sound as if integration tests lie above unit tests. –  Martin Ba Oct 4 '11 at 13:35
3  
@Martin: From the linked post: If you automate this sort of testing in order to detect breakages when they happen in the future, it’s called integration testing. AFAIK, this statement is wrong, this is the definition of regression testing. Integration testing is exactly as Thomas says, one level above unit testing (you test how well your units integrate into a system). –  Treb Oct 4 '11 at 13:57
    
@Martin That post gets a few definitions and concepts, including TDD and integration testing, wrong, at least based on the standard definitions that I've learned. –  Thomas Owens Oct 4 '11 at 14:08
    
+1 thomas - this is an extremely common misconception; TDD tests scale, unit through acceptance, because they test features, not modules. Should never have called them 'unit' tests, too confusing! –  Steven A. Lowe Oct 5 '11 at 3:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.