DevOps Zone is brought to you in partnership with:

Dave Bush is a .NET programmer and Certified ScrumMaster who is passionate about managing risk as it relates to developing software. When he is not writing or speaking about topics related to Application Lifecycle Risk Management (ALRM), he is an example to his peers as he develops web sites in the ASP.NET environment using industry best practices. Specific topics Dave can address include: • Project management, with an emphasis on Scrum • Test Driven Development (TDD) • Behavioral Driven Development (BDD) • Unit testing and Integration testing using NUnit, Jasmine and SpecFlow • Web Application testing using Selenium • Continuous Integration • Extreme programming (XP) • Coding best practices • Architecture • Code Reviews Dave has "an insatiable curiosity and is always learning." He has been called "the miracle worker" and "hard to replace" by clients he has worked for recently. Contact Dave via LinkedIn ( to find out more about how he can help your organization reduce software development risk Dave is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Why Don’t You Practice Test First Development?

  • submit to reddit

 I would have said “Test Driven Development” but I want to make it clear that what I’m talking about is writing test first, or at least simultaneous to writing the code.  Not sometime after, even if that after is immediately after.

Recently, I’ve been doing some Test First Development presentations and I’m finding a trend that I’d like for you to contribute more information to.  While just about everyone I talk to will say they believe that we should be practicing Test First Development, hardly anyone is actually doing it practicing Test First Development.

So, the question I have to ask is, “Why?”

So, leave me a comment and tell me why you aren’t writing test code first.

Published at DZone with permission of Dave Bush, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Gurunath Lohar replied on Fri, 2014/02/21 - 6:30am

We are not able to write tests first because

1. We need to change the files which are shared among multiple teams. The code change is limited to adding few blocks of code/removing certaining conditions in these shared files.

2. Not having all the information before starting the development. We start with available information and later change according updates/changes suggested.

3. Creation of some objects which are part of framework, need server to be running. Like configuration objects. 

Thank You


Andre Bogus replied on Fri, 2014/02/21 - 8:16am

Mostly programming exploratively. Writing tests for code that's going away in a minute because I am not yet sufficiently smart about the target domain is wasteful.

Deryl Spielman replied on Fri, 2014/02/21 - 5:59pm

It takes time to learn a new skill. Not everyone is willing to invest in a new method when their current method works. Another reason is that test cases or acceptance criteria are lacking or not well thought out. 

Dan Hrivnak replied on Fri, 2014/02/21 - 11:41pm

If the acceptance criteria isn't thought out then I'd argue there's no business writing the code. If you don't know what it should do enough to think of test cases, you aren't ready to start coding.

Jean Said replied on Sat, 2014/02/22 - 6:52am in response to: Dan Hrivnak

You would end with no project starting if your were to work at my workplace, mate. Having partial information and guessing what is right is what most development is about. Unless you develop using a proven mathematical model, of course.

But well, I do agree that you should try to have clear test cases in a first place, even if you have nobody to prove or disprove these formally. I say should, because an information system is a living thing, and you always end with some unknown parts where the code is the specification. Unless your business is simple, of course.

So, pragmatically, we end up creating test cases in parallel with our code (kudos to our dev team dedicated tester). Then we code the solution and the executable specifications, more or less in parallel. In the end, we adjust the executable specifications and code if there are some motivated mismatches.

So in a nutshell, while we try to do TDD and BDD, we try not to be overly zealous about it. As specifications are never complete, even when discussed throughly with the product owner, we tend to fix them if necessary.

Please do not refrain from living in a perfect world with executable specifications engraved in stone and never change in eons ;)

Serguei Meerkat replied on Sat, 2014/02/22 - 3:14pm in response to: Deryl Spielman

It takes time to learn a new skill.

And by the time you learn it, there is a good chance that the next fad (sorry - method) will come up :)

Serguei Meerkat replied on Sat, 2014/02/22 - 3:29pm in response to: Dan Hrivnak

 If the acceptance criteria isn't thought out then I'd argue there's no business writing the code

We know acceptance criteria of the whole function that can take, say, a month to develop. And with TDD we are talking about unit tests and we supposed to write a bit of test at a time and then see it green, do we? What acceptance criteria we are talking about?

I personally find that with the new code it is better to grow tests in parallel with the code (sometimes code comes first, sometimes test comes first), while when fixing bugs it is almost always better to create a failing test first.

I am really not sure that the code TDD idea that somehow tests should drive a design is a good idea. It seems to me to be a completely stupid idea. One of those that come to IT industry regularly and then fade away to be replaced by another one.

Dan Hrivnak replied on Sun, 2014/02/23 - 9:52pm in response to: Jean Said

Don't get me wrong - I've never seen the full vision thought out for any software project or task. But like you said, before coding something you at least should have an idea of what kinds of tests might make sense. I'm not strict on TDD or BDD but I *try* to have at least some test cases written before writing too much code. And yes, they will likely change as you go and as more requirements are forced out of the stakeholders. :)

Gurunath Lohar replied on Sun, 2014/02/23 - 10:05pm

Thank you ALL for the valuable suggestions


Luca Cavagnoli replied on Mon, 2014/02/24 - 5:59am

Because [Insert poor excuse for laziness].

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.