Are "TDD Tests" different to Unit Tests? [duplicate]

Question

I read Stephen Walther's article about Test Driven Development (TDD) and unit testing.

I think it was an excellent article.

The author makes a distinction between what he calls "TDD Tests" and unit testing. They appear to be different tests to him.

Previous to reading this article I thought unit tests were a by-product of TDD. I didn't realise you might also create "TDD tests".

The author seems to imply that creating unit tests is not enough for TDD as the granularity of a unit test is too small for what we are trying to achieve with TDD. So his TDD tests might test a few classes at once.

At the end of the article there is some discussion from the author with some other people about whether there really is a distinction between "TDD Tests" and unit testing. Seems to be some contention around this idea.

The example "TDD tests" the author showed at the end of the article just looked like normal MVC unit tests to me - perhaps "TDD tests" vs unit tests is just a matter of semantics?

I would like to hear some more opinions on this, and whether there is / isn't a distinction between the two tests.

Answer 1

I like TDD video by Roy Osherove especially the part about 'What does TDD mean?'.

It all depends on what you 'drive' by TDD (design or development, or both or ...) and what the 'unit', that is under test, really is.

The term Unit Testing has become overloaded. Programmer tests might be more precise and might help clarify better the role this kind of testing plays in TDD practice. I think he is really comparing programmers tests and the tests that cover more than one class/method/module.

I don't think that TDD practice exclude any type of testing to be the 'T'. It is a practice and it is not really a type of test (as someone pointed out in the comments).

However, TDD has the most obvious effect at the lowest level (at method/function level) hence programmers tests are most often used and indirectly assumed when talking about TDD. But TDD as a practice is still quite possible when you move up (pre-integration or integration tests) as well. It just becomes a bit more difficult to quickly link the failing tests with the line(s) of code that needs to be added/modified.

Answer 2

TDD tests Features, not "units"

sometimes features correspond to units, sometimes they don't. Usually they don't.

TDD tests scale - up or down - as required to test a feature. If a feature is 'must transmit daily updates in less than 500msec' then the TDD test will look like a unit test. If a feature is 'must construct correct widget prototype bindings with six optional branch structures' then the TDD test will look like an acceptance test. [features paraphrased, obviously]

Caveat: didn't read article; read Beck

Answer 3

Even though I have no experience with TDD, I will add my own opinion on this ;-)

The article says that the approach of TDD leads to tests that may not adhere to the principles of a Unit Test, specifically testing in isolation. You could say that unit tests are more bottom-up, while TDD-Tests, coming from the user stories, have a top-down approach.

I think that

1. He is right about that
2. He makes a poor job of explaining it
3. If you see it happen, you should refactor your tests. Don't give them a different name (e.g. TDD-Tests) and feel fancy because of it, but turn them into proper Unit Tests.

Answer 4

FWIW, I use the term "TDD test" to refer to the tests that come out of the TDD process, and "unit test" to refer to those tests that would verify that a "unit" meets its specification. The two aren't exactly the same - a TDD test (the way I use the term) always precedes an addition of code to the unit under test, but such tests are not necessarily adequate to the verification of a module. Consider a trivial function like isBetween - given a range and a number, verify that the number falls within the range. Implementing with TDD, we might come up with:

# first pass
def test_LowerMeansNotInBetween
    # zero is not between 2 and 4
    assert_false(isBetween(2, 4, 0))
end
def isBetween(low, high, testVal)
    false
end
# second pass
def test_BetweenMeansInBetween
    assert(isBetween(2, 4, 3))
end
def isBetween(low, high, testVal)
    low <= testVal
end
# third pass
def test_GreaterMeansNotInBetween
    assert_false(isBetween(2, 4, 5))
end
def isBetween(low, high, testVal)
    (low <= testVal) && (testVal <= high)
end

At this point, isBetween should be functionally correct (but I haven't actually tried running it, I could be wrong -- this is just for sake of illustration), but the tests do not fully exercise the specified behavior. For that, we might need at least the following tests:

def test_AtLowerBoundMeansBetween
    assert(isBetween(2, 4, 2))
end
def test_AtUpperBoundMeansBetween
    assert(isBetween(2, 4, 4))
end

which didn't cause us to update any code. The way I see it, all five tests are "unit tests", but only the first three are "TDD tests".

Answer 5

as @Steven said, TDD tests should test features, or more generally they test use cases. Unit tests have a different, smaller scope: test the class implementation from its interface as a single unit of delivery; it constitutes an acceptance test for a single class

think of TDD as producing a set of acceptance tests that are required for a certain sprint on a whole project, so the purpose of the sprint is making the acceptance tests pass for all the project running as a single unit.

the set of all use case tests, or acceptance tests is a guarantee that the software does what the stakeholder has asked the team to implement

Answer 6

YES

Unit test alone is basically a method for testing the smallest logical part of a program.

TDD is a software development process. It basically tell you how to use unit test methods in a more agile way.

In other words, unit test answer the questions "what to do?" and TDD answers, "How to do it?"

update: I feel what he meant by TDD test is feature testing.

Answer 7

I don't think there's really a single correct answer to this. TDD gives some guidance what sort of tests you should write, and how they should relate to the rest of your development.

Depending on who uses the term, however, "unit test" can cover such a wide range of possibilities that it almost inevitably covers most TDD tests -- but then, you'd probably have a hard time finding any test that at least a few people wouldn't be willing to call a unit test...

Bottom line: the tests advocated by TDD cover a fairly wide range, but there's at least some agreement about what they are. "Unit test" is so poorly defined that it can refer to almost any sort of test. As a term, it means almost nothing.

Answer 8

There used to be an IEEE definition for unit testing that I liked because it was more general and didn't go with the whole TDD concept of testing the smallest testable units possible. Now that definition has been altered to match the EP-version which I find silly. To me, unit testing means checking points of interaction between larger sets of components where you're most likely to have some volatility when changes are made. If you see variations on definitions out there, it's because the phrase got co-opted by the EP/TDD crowd. I find it one of the more irritating phenomena in programmer culture. Why can't we just come up with new phrases rather than re-invent old ones?