Ran across this statement by Martin Fowler circa 2002:

Unit testing in XP is often unlike classical unit testing, because in XP you're usually not testing each unit in isolation. You're testing each class and its immediate connections to its neighbors.

Is this still correct, and if so, why?

closed as primarily opinion-based by user40980, gnat, Bart van Ingen Schenau, user53019, jwenting Sep 18 '14 at 12:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    recommended reading: Discuss this ${blog} – gnat Sep 12 '14 at 20:32
  • 3
    @gnat: Happy to remove the reference to Fowler, but it's unclear if that's your point. – blunders Sep 12 '14 at 20:37
  • @blunders consider trying to make the question stand on its own without using the quote and opinion of a blog author. – user40980 Sep 12 '14 at 21:24
  • 2
    @MichaelT He wrote one of the go-to books on specific practices in extreme programming. This isn't just the opinion of a random blog author. – Izkata Sep 13 '14 at 1:34
  • 1
    @Izkata I am well familiar with his notoriety. That doesn't mean that asking about an out of context quote from something he said when he was trying to publicize XP from over a decade ago makes for a good question. – user40980 Sep 13 '14 at 2:26

What he's describing is a difference between unit testing (testing a unit in isolation, in this case a class but you can test each method if you're masochistic enough) and integration testing where you test the class and also how it works with other classes. That's not unit testing - you're not testing the unit but 'many units'.

I believe the latter is better, the trouble with it is that it is more difficult to achieve total code coverage - ie to test every part through the system. IMHO even if you unit test each and every method, you still have to test the paths through the system anyway to make sure they work together. (for example, I can test a usb plug and guarantee it works, and test a usb socket and prove it works.. and then they'll work perfectly when assembled.. but my plug is a type A and my socket is a type B, d'oh. This design flaw should never have been there in the first place, but we can say that about any bug, which is why we test things).


Well, why don't we just ask the man himself?

Despite the variations, there are some common elements. Firstly there is a notion that unit tests are low-level, focusing on a small part of the software system. Secondly unit tests are usually written these days by the programmers themselves using their regular tools - the only difference being the use of some sort of unit testing framework. Thirdly unit tests are expected to be significantly faster than other kinds of tests.

So there's some common elements, but there are also differences. One difference is what people consider to be a unit. Object-oriented design tends to treat a class as the unit, procedural or functional approaches might consider a single function as a unit. But really it's a situational thing - the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing. Although I start with the notion of the unit being a class, I often take a bunch of closely related classes and treat them as a single unit. Rarely I might take a subset of methods in a class as a unit. However you define it doesn't really matter.



A more important distinction is whether the unit you're testing should be isolated from its collaborators. ... But not all unit testers use this isolation. Indeed when xunit testing began in the 90's we made no attempt to isolate unless communicating with the collaborators was awkward ...

On his blog he shows some pretty nice illustrations and explains what he means in a pretty good depth.

So when wondering what Martin Fowler means and whether or not it's still true today, I think Martin Fowler of 2014 is the best possible source.


TDD or Test-Driven Development is where you would create a failed unit test on a method first, write the method code second, then see if the test passes. If it doesn't, you refactor the code until it passes and then move on to your next unit test of the same method. You don't have to use TDD to create unit tests. You can write the method first and then create unit tests for it second making sure each test passes. If you're testing a class, you run in to integration testing because it may call out to a data layer which communicates with the database. To avoid that you'll need to use a mocking framework so that your tests can be automated and not rely on connections outside of your application.


11 years later I would state it this way:

Unit testing in Agile is often unlike classical unit testing, because in Agile you're usually not testing each unit in isolation. You're testing each class and its immediate connections to its neighbors.

Note: This is still distinct from integration testing where you are testing the code and its dependencies and required services.

  • 1
    Thank you for the effort, just to be clear, it's my understanding that your answer just switched XP for Agile, which I personally don't believe is valid. Am I missing something? – blunders Sep 12 '14 at 20:58
  • Just pointing out that Agile is the new flavor of XP with some similar philosophies and adding that a more important distinct might be when integrated testing is being done. – Michael Durrant Sep 13 '14 at 18:26
  • I see, guess I saw Fowler's statement as being unrelated to integration testing; which appears based on the other answers to have been the case, though it's possible I've some how misunderstood. – blunders Sep 13 '14 at 18:47

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