I was wondering when most people wrote their unit tests, if at all. I usually write tests after writing my initial code to make sure it works like its supposed to. I then fix what is broken.
I have been pretty successful with this method but have been wondering if maybe switching to writing the test first would be advantageous?
whenever possible i try to follow a pure TDD approach:
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!
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.
I follow a TDD approach, but I'm not as much of a purist as some. Typically, I will rough in the class/method with a stub that simply throws a NotImplementedException. Then I will start writing the test(s). One feature at a time, one test at a time. Frequently, I'll find that I've missed a test -- perhaps when writing other tests or when I find a bug -- then I'll go back and write a test (and the bug fix, if necessary).
Using TDD helps keep your code in line with YAGNI (you aren't gonna need it) as long as you only write tests for features that you need to develop AND only write the simplest code that will satisfy your tests.
We try and write them before hand, but I will fully admit, that our environment is chaotic at times, and sometimes this step is initially passed over and written later.
I usually write a list of the unit tests I will be writing before I write the code, and actually code the unit tests after, but that's because I use a program to generate the unit test stubs and then modify them to test the appropriate cases.
I tend to use unit tests to test the code as I'm writing it. That way I'm using what I'm writing at the same time, as I use the unit test to test code while I'm writing it. Much like a console app would.
Sometimes I've even written tests without asserts, just debug outputs, just to test that how I use something is working without exceptions.
So my answer is, after a little bit of coding.
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.
I'll offer that I'm fairly new to writing unit tests, and that I wish I had written them before I wrote my code. Or, at least had a better understanding of how to write more testable code as well as a better understanding of concepts like dependency injection which seems to be critical to writing testable code.
Normally I write unit tests before the code. They are very beneficial and writing them before the code just makes sense. Dependency injection lends itself well to unit testing. Dependency injection allows for parts of your code to be mocked out so you only test a particular unit i.e. your code is loosely coupled and it’s therefore easy to swap out for a different (in this case mocked) implementation.
