Understanding the difference between "test-first" and "test-driven"

Question

I've had conversations about this topic in the past, and I think I might know the answer, but I've not been able to articulate it properly.

Here's what I think I know:

I suspect you are test-first rather than test-driven if you already have the idea in your head of how things will work before you write tests, so you write tests first that will test your idea before implementing your idea. I.e. Your idea of the implementation comes first, and drives what the tests look like.

If you're test-driven then you're trying to get the test to drive what the implementation looks like. You write a test for some behaviour you want rather than a preconceived idea of the implementation, so that you have to come up with an implementation in the "refactor" stage to pass the test well.

My questions are:

Have I understood this correctly?
How does one get into the test-driven mindset from the test-first mindset, when it's natural for most developers to immediately start exploring solutions in their mind before they even reach out for the keyboard?

I'd welcome suggestions to edit this question to avoid it being closed, if anyone would like to leave some as comments... — Neil Barnwell, Oct 06 '11 at 11:48
Maybe move to http://programmers.stackexchange.com/ as it seems more appropriate there? — Sardathrion - against SE abuse, Oct 06 '11 at 11:51
Oh dear. I really lament the creation of programmers.se.com, because SO.com is described as "a programming Q & A site" on it's about page. How on earth does one know the difference? Oh well. Thanks for the tip. — Neil Barnwell, Oct 06 '11 at 11:56
Look at the FAQs for both. Note that since my whuffies are so low, you should take my answer with a pot of salt -- I could be mistaken. — Sardathrion - against SE abuse, Oct 06 '11 at 11:59
Possible duplicate of http://stackoverflow.com/questions/334779/is-there-a-difference-between-tdd-and-test-first-development-or-test-first-progr — Raedwald, Oct 12 '11 at 00:20

score 4 · Answer 1 · answered Oct 06 '11 at 12:05

4

The key aspect of test-driven development is that you do not implement functionality that is not required to pass a test. Test-first simply means writing the test before you implement the functionality. This is mostly done to ensure that the test will actually fail if the functionality is not present. Test-driven development implies a test-first approach, but not the other way around.

answered Oct 06 '11 at 12:05

Björn Pollex

75,346
28
201
283

A related question: http://stackoverflow.com/questions/276813/what-is-red-green-testing – Raedwald Oct 06 '11 at 12:45

score 1 · Answer 2 · answered Oct 06 '11 at 12:37

I think you've understood and articulated pretty well the distinction between test-first and test-driven, and as Björn points out, all test-driven development is necessarily test-first. To your question of how to get from a test-first to a test-driven mindset, I'd suggest working a relatively simple exercise (say, implementing Range or Rectangle) several times, trying to arrive at a different implementation each time. The first time through, you'll come up with what you are thinking of right now - and that's not test-driven, as you point out. The next time through, you can't use what you're currently thinking; you'll have to reach out to come up with something different, and some of that reaching will happen in the presence of a failing test. Maybe the third time through, you'll begin to discard your preconceived solutions, and just do what the test compels you to do - and you're on your way to a test-driven mindset.

If the exercise is not to your liking, try simply writing your first test sooner. Don't do the analysis up-front. Just, on taking on a problem, first write a test. Now you can do your thinking about the problem with the test "looking over your shoulder". It'll be uncomfortable for a while, but out of the discomfort should emerge a new way (and I think a nice one) of looking at problems.

score 0 · Answer 3 · answered Oct 06 '11 at 11:55

Writing a set of tests before implementation allows you to make the unit tests for the public methods. So, the real implementation of what is happening is hidden from the test. You are coding to an abstract rather than an implementation which is a good thing (TM). You are taking in abstract terms and concepts -- the tests will form what your public methods will be. So, test driven mean that your tests will drive the API. The reverse is what you call test-first.

score 0 · Answer 4 · answered Oct 10 '11 at 05:50

The difference is Role and Interface discovery.

If you're writing your tests before you write code, you get the Test-First badge.
If you're Test-First and you listen to your tests to discover what types/roles/interfaces are needed and "grow" your design via JIT refactoring, then you get the Test-Driven badge.

With test-first, you're likely to jump to a design (which may/may not be the simplest/optimal choice ; based on your skill) before you write the tests. Test-first is also easy to shoehorn tests onto a bad existing design, however progress would be slow. You're likely to end up with hard-to-test code and slow-to-write tests.

IMHO Test-driven helps me to write simpler designs that are easy to test.

How to get into the mindset ? : That's the part where you need self-discipline and practice. Yes it is difficult to keep your mind from racing to solutions. +1 to Carl for pointing doing some code-katas in exploratory mode, Make different choices and see how it ends up. With a few under your belt, it becomes easier... TDD actually causes you to "focus" on one thing at a time.

Understanding the difference between "test-first" and "test-driven"

4 Answers4