Not Using Test-First? You're Doing it Wrong.
Join the DZone community and get the full member experience.Join For Free
many teams are struggling with delivering modern software because they are not building with test first principals. test first gives us the assurance that we have built the correct thing, that what we built is what the customer asked for and that when we change things we don’t break anything inadvertently.
if you look up test first on wikipedia you will be redirected to the test driven development (tdd) page and i believe this to be incorrect. while tdd is one, arguably the most effective, form of test first it is by no means the whole thing. can i achieve test first with no automation at all: yes. can i do tdd with no automation at all: no. do you see my conflict…
if you are building applications without writing your tests first then you are doing it wrong. your process will result in significant rework, be less maintainable and be less likely to meet the customers needs. scottish software proverb (just made it up, and i am scottish)
unfortunately while the proverb above is absolutely true there are many fanatics that will not accept that you can do test first without automation. just like the process wars the practice wars are being waged around us, and while we want to endeavour to be agnostic it is not possible to be an atheist.
you will hear a lot of different terms banded about in relations to test first:
- test-driven development (tdd) – automated tests created before code is written to validate that we need that code.
- acceptance test driven development (atdd) – tests, either automated or manual, that validate business functionality
- behaviour driven development (bdd) – an automated test that validates a particular behaviour that you want your application to have.
these terms all fulfil a specific niche and the evolution of modern software development will sprout many more. find that which solves your specific problem and adapt until you have something that works for you, your team and your organisation.
the essence of test first
test first has two main goals, both of which are as important as each other.
the first is about professionally validating that which you have built. code is complicated and one can easily create unintended results when that code is executed. this is not a quotient of poor programming but of the complexity of the task. in the eighteen hundreds plumbers pumped smoke through the pipes to make sure that there were no leeks on the grounds that if it is good enough for smoke it is good enough for water. this mentality has resulted in what we now call the ‘smoke test’ in software development and the result of its implementation is bugs in production. when compared to software development plumbing is simple; modern software is many times more complex than software was even 10 years ago. we have accepted poor quality deliverables and expensive maintenance for far too long.
the second goal is to shorten your feedback loops. the closer our engineers are to when the problem was created the quicker they can find it and the cheaper it is to fix. unfortunately it is impossible to tell in most software what ‘right’ looks like and developers just take a guess. the attitude that a problem, if it exists, will be caught by quality assurance (qa) or user acceptance testing (uat) is unprofessional at best and incompetence at worst. we want to know that what we have just written not only meets our customers expectations, but also does exactly what we intended for it to do under as many circumstances as we can think of.
test first allows us to mature from simply testing quality in towards building that quality in from the start jeff levinson , architect at boeing
fundamentally it is far cheaper to fix an issue closest to it’s source. the longer we leave the finding of that defect the more expensive it becomes. a bug found in production is 10 times more costly to fix than the same bug found in development.
the three virtues of test first:
- validation of building what was asked for
- validation that what we have built works as we intended
- validation that changes have not broken original intent
ideally we want our tests to be as close to the code as possible, but also as easily understood by the customer as possible. ideally all of our code is automated and we have an executable specification. its a balancing act…
business validation – we have built what was asked for
getting validation that we are building the right thing is key to actually being able to build the right thing. this sounds like a no-brainer but what do we usually do?
well, we usually take our requirements, in whatever form we generally make them, and give them to our coders to turn into working software. quite separately we give the same requirements to our testers and they create a bunch of tests to validate what we have built.
did you notice the problem with this workflow?
the worst that can happen is that we built exactly what the customer asked for!
how can we ever build to meet the measure if we don’t build to what is to be measured? we need to flip that on its head and instead have the tests created first (the measure) and then code to make the tests pass. now that we have removed the inevitable time consuming rework we can take that time and use it to create even more value for our customers.
in addition we are far more likely to be able to meet our customers expectations now we have an additional level of focus provided by those tests.
developer validation – what we have built works as we intended
its now 2013 and gone are the cowboy days of the late nineties and early naughties . software engineers can no longer hide behind their management as ‘not giving approval to do unit testing’. this is about professionalism and all developers, no matter what they are working on, should be validating the work that they do.
you are not a professional if you do not do the due diligence necessary to validate what you have created works as intended and continuous to do so.
there are two main value adds here. the first is that when a coder creates functionality it does exactly what he intended and we have a record, and executable specification, of what that intent was. the second comes later. when we go to add functionality later we know when we have broken existing functionality and that is one of the most valuable parts of this endeavour.
can you imagine how amazing it would be if you could use this executable specification to validate all future changes don’t break your application.
while it takes time, effort, dedication and discipline to achieve test first the return on investment is enormous. we meet more of our customers expectations, we minimise our maintenance costs and get less regressions and bugs in production.
the only question for a professional development team is where too sign up!
Published at DZone with permission of Martin Hinshelwood, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.