Jason Whaley is a Java developer specializing in service oriented architectures, enterprise integration, cloud computing, and continuous integration. Previously, Jason has worked in multiple roles for both public companies as well as government institutions in a variety of roles for several broad ranging Java based projects. Presently, Jason works at Nodeable as a platform developer where he is helping build a next generation infrastructure monitoring and analytics tool. He is also a contributor to The Basement Coders Podcast. Jason is a DZone MVB and is not an employee of DZone and has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

Why I Write Tests

  • submit to reddit

My tests aren’t for me. They are for you… and you, and you, and you!

Writing tests for me isn’t about trying to prove correctness in my program - at least when you get down the core of why I write tests. Sure, while I’m writing the test and before I write the corresponding production code I do so to verify my assumptions about what I’m about to create or edit. This is otherwise known as Test Driven Development. Though TDD keeps me honest, I’m not positive the time and effort spent doing TDD is really worth it if keeping myself honest is the only reason.

The time savings for me ultimately come further down the road. The benefit is gained when I or someone else comes back a week later, or perhaps even or a month later, and makes some changes to production code covered by those tests I wrote during TDD and those changes fail existing tests. That is a sign that what is being coded now is trampling over code that enforces assumptions that have previously been made. If those test failures didn’t occur because the tests weren’t there, or heaven forbid if the tests were inadequate, then you are asking for that new feature/bugfix to be implemented but are then introducing 0..N bugs in the process of doing so.

That’s why I like to have tests. I want my build system and my CI server to a raise a bloody fit if a test breaks.

The tests breaking should be a conversation starter about what expect the code under test to do when those tests fail and then consider how the new feature/bugfix can coexist with or peacefully change the assumptions those failing tests are protecting. That ultimately leads to a cleaner code base, a code base that is more widely understood across the team, and fewer bugs introduced. That’s where the time saved. That is why I write tests.


Published at DZone with permission of Jason Whaley, 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.)


Partha Bhattacharjee replied on Sat, 2013/02/23 - 1:30am

I guess these opinions are quite darn personal and there is no right or wrong one. Personally I do not write any test at all for anyone else apart from me. I write tests because when I write tests I keep my code and design relevant, practical and down to earth. I find it too easy to get drawn into - often pedantic - conversations about "correct design patter to use" in my own head. And, might be just a personal issue, but too often after a while I have been musing about a problem, I find it very difficult to come back to the ground. The practicalities of implementing the feature / solving the issue e.g. that pesky little thing called timeline for production release gets lost.Writing tests make sure that I write the code, with an eye towards the client e.g. the client api that is going to use it, keep writing stuff that is actually currently required (often with copious comments explaining what the golden solution would have been and how I vow to come back and do that sometime later). In my mind - as a developer - this is the main reason I write code. I quite understand and appreciate the other reasons e.g. code coverage, easy and early detection of regression bugs etc etc. But to be absolutely honest, as a developer they don't help me on a day to day basis, as I write code. Again, just my personal opinion and no disregard / disrespect to any other opinion expressed here.  

Comment viewing options

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