Do you write your unit tests before or after coding a piece of functionality? [closed]

Answer 1

whenever possible i try to follow a pure TDD approach:

1. write the unit tests for the feature being developed; this forces me to decide on the public interface(s)
2. code the feature ASAP (as simple as possible, but not simpler)
3. correct/refactor/retest
4. additional tests if required for better coverage, exceptional paths, etc. [rare but worth consideration]
5. repeat with next feature

it is easy to get excited and start coding the feature first, but this often means that you will not think through all of the public interfaces in advance.

EDIT: note that if you write the code first, it is easy to unintentionally write the test to conform to the code, instead of the other way 'round!

Answer 2

I use Test-Driven Development (TDD) to produce most of my production code, so I write my unit tests first unless I'm working on untestable legacy code (when the bar to write the tests is too high).

Otherwise, I write functional-level acceptance tests that the code shall satisfice.

Writing the unit tests first allow me to know exactly "where I am" : I know that what has been coded so far is operational and can be integrated or sent to the test team ; it's not bug free but it works.

Answer 3

I really want to write the code first, and often do. But the more I do real TDD, where I refuse to write any code with out a test the more I find I write more testable code and better code.

So, yes, write the test first. It takes willpower and determination, but it really produces better results.

As an added bonus, TDD has really helped me keep focused in an environment with distractions.