Do we have time to write tests on our projects?

This is a question I would like to answer in the context of my day job.  It came up again today as I was talking with the other developers about some of the “new methods” I would like to integrate into our development process.  The title of this post is how the question sounds now in my head.  This afternoon it went more like this: “We don’t have time to write tests on our projects!”

Granted the developer who made this statement is a big believer in the “speak first, reason it out later” method of communicating… this is his knee-jerk reaction to someone telling him we would write more code for the same functionality.  I can sympathize with him… we have deadlines on our projects to meet.  But I don’t agree with him.  I’ve already written some tests at work to solve a problem in the business logic of software we released 2 months ago.  The exercise helped me find other problems in that code and refactor it to a state that will be much easier to maintain.  Do we have time to maintain legacy code that is hard to understand and has no tests written against it?  I don’t.

But… even though I am convinced we need to write tests, I want to be practical.  Will my team benefit from this?  Are there certain types of developers or certain types of projects that will never see the benefit of writing tests against code?  Maybe so – but I hope that isn’t a description of the team I work with.  And I think the best way to find out is to do the best I can to set us up for success.  That is a big reason I am writing about my experience building up the NCharlie project.  I have some work to do before we are there though.  As I mentioned before, TDD still feels like a pain point for me because of the way my tests look using Rhino Mocks to mock objects like the database access code.  When I mentioned this pain point to my boot-camp instructor his advice was to “abandon ship”… not on TDD, but on the Rhino Mocks Expect-Replay-Verify model and use the easier to understand Arrange-Act-Assert model of testing (I know AAA is possible with Rhino Mocks… but not with nice syntax in .Net 2.0).

So, I am going to follow my instructor’s advice and abandon ship.  I’m going to start writing tests without a mocking framework.  I can create a class quickly that mocks a database access class without using Rhino Mocks.  Sure it will be a bit more code to write, but I think the clarity it will bring to the tests will be worth it.  I also think it will be a good exercise even if I do end up coming back to a mocking framework like Rhino Mocks… I will appreciate it more after manually building mock objects.

This means I am going to stay on the topic of writing tests for at least one more post.  Earlier in this series I wrote some tests to verify that the controller class for the Task Search page in the NCharlie project was correctly responding to events raised in the view.  I didn’t show the code for the test in the post (it was available in the code repository) because I did not want to distract from the intent of that post.  Now it is time to show that code… almost (actually, in the next post).  First, let me answer the question I posed in the title of this post:

Yes, we do have time.  It will make us go faster because our code will end up being easier to work in now, and easier to extend or fix later.