Why Testing Makes a Project Successful and You Can't Afford to Deny It

According to <prweb.com>, recent Cambridge University research found that, on average, software developers spend 50% of their programming time finding and fixing bugs and estimate that this costs the global economy $312 billion per year.

Don’t be part of that statistic

Like many of us, despite being told repeatedly how great testing is, the benefits it will bring, the time it will save and how it will improve the quality of my applications, I too considered testing a second-thought.

I saw it as something which was both expensive and time-consuming. If I was genuine with you, I’d say I believed it be be nothing more than a “nice to have”, after the application was written. If you also feel (or have felt) this way - know that you’re not alone.

What made it even more difficult for me, was hearing people regularly reinforcing these false and ultimately costly assumptions and beliefs. I’d start to get excited about it, only to hear a variety of the following phrases:

• Testing is too expensive
• Testing is too time consuming
• It’s too difficult
• It will take time away from real development
• The client’s not prepared to pay for it

So, possibly sadly, it’s only in recent times that I’ve started getting involved with TDD, BDD and related techniques.

But it’s never too late to begin!

 Testing Can’t Be an After-Thought

It’s treated as an after thought, a nice to have, an academic or utopian ideal that really can’t or doesn’t exist in the real world. Yet people wonder why projects regularly over-run both on cost and time and countless hours are spent bug fixing. The net result is we have a botched reputation and the joy of development saps away somewhere to die.

However, what’s reassuring to me is that the more I look around recently, the more projects I see that have testing not only as a serious going concern, but as an integral part of the development mindset.

As a result it becomes a natural part of the development process. It becomes integrally interwoven in the mindset of the application. If you’ve not seen them, here’s a small selection:

• Zend Framework 2 (integrated PHPUnit and Zend Test)
• jQuery & Node (Mocha, QUnit, should.js, expect.js, chai, better-assert)
• Grunt
• Silex
• Symfony

But It’s Not Always Easy

If you’re on the Malt Blue mailing list, you’ll know that recently I’ve undertaken a new Zend Framework 2 based project. In that project, I’ve been determined to correct my bad development habits and really take on a test-centric approach to development.

But as the saying goes the road to hell is paved with good intentions. And so it seemed at first with the project. There I sat, all excited to be testing, testing, testing. And at first, all seemed well.

Then it became difficult. I’d write loads of tests, for a range of components all at once, run the test and be faced with a litany of failures, across a range of different components. I’d start working through them, find more, fix them, find more and so on.

In the last post here on the blog I expressed my sense of dismay at the stress that was resulting from it all. Luckily, I am fortunate to have a very educated, wise and calm testing mentor in the form of a former colleague and friend.

Through much time, chatting on Skype, he gave clear guidance in how to approach it. I’ll skip over the full conversation but give you this one gem that he gave me.

Write just enough tests to test the smallest part of functionality, then implement the code and retest until it the tests pass.

A Simple Test Perspective

With that change of perspective, instead of trying to build the controllers, entities/models and related components, I took on a simpler approach, which is painlessly simple to follow. The image below describes it best.

I decided to just start building entities alone. I began afresh, writing a test first, then adding code to the entity accordingly. No more, no less.

Then, when the entity was complete, I built the form that would use the entity. I wrote tests first, then the coded the form itself. Following this, I built one or two TableGateway classes, as that’s what I’m using (maybe Doctrine on another project).

This change brought about a rapid escalation in productivity. Doing one thing well, then another, then another, produced great progress.

Was it Practically Working?

After a while however, I started to doubt the validity of what I was producing. It was great that I had all these tests for the individual components. But how would they go when they were bound together later on.

With a pressing deadline, I was rather concerned that maybe I was in the grip of an engrossing illusion. I held fast, thinking that no, this was a new path, one I’d not trodden down much before. I can’t just stop because I feel slightly uncomfortable or unsure.

But later the concern returned. So this time, I put the testing on pause and thought:

I’ll put one entity, form and table gateway together and just see how it goes

So, using the wonderful ZF2 service manager (for sakes of simplicity), I did just that.

I can’t express the amount of relief, joy, happiness and satisfaction I felt as I looked at what was rendered in the browser and how it operated. It 100% matched the mocked world of the tests which I’d been creating.

One fear still remained though:

Was the application development time, in some way increased, because of the time spent writing the tests?

In answer to you, initially it felt and still does in part, feels that way. But I believe I’m seeing a better placement of effort. I like to compare it to the anecdotal experiences of Windows and Linux systems administrators.

With Windows, you can seemingly get a system up and running quickly, but may spend a lot of time with it later. With Linux (and speaking from personal experience), you may spend a lot of time at first, doing a lot of things, but when it’s done, it’s done.

Just leave it, monitor it occasionally and it will just keep on humming. Now no, this isn’t a true and accurate reflection of reality, but the sentiment is correct. My experience can be summed up in one word.

Confidence

• Confidence that what I’ve made works as intended
• Confidence that when code is shipped it will work
• Confidence that the time spent in development, is not wasted (or just a downpayment on time to be spent later)

There’s phrase that also fits - Peace Of Mind.

When we’re working for others, but especially more so when we’re private freelancers, both us and our clients need peace of mind. If you aren’t confident that your code works (arrogance is no compensation), then how can we be sure what we give to our clients works?

How do we know that they won’t ring us up in the middle of the night, days, weeks or months later with a “seemingly random” bug. How do we know that the relationship that is so important, will grow and prosper.

In short, how can we rest assured that when we believe we’re finished (and grab that beer) that we **actually are? **I hear the questions coming already:

• What if you haven’t tested everything?
• What if the tests you wrote are wrong?
• What if you didn’t’ think of certain edge cases?

These are all valid questions, each and every one. And they will all happen from time to time. But the key take away from this article, is that at least by having tests, we’re in a much stronger position. If we find bugs, we add in regression tests, fix the error and move on, having tests in place to catch that.

Balance

This leads me to the last part of today’s post - balance. Testing can be just like a shiny toy. Once we have it, we want to do everything possible with it. So much so that we spend more time writing tests, even for situations where it’s not necessary to have them.

So, whilst I’ll be writing more about testing from now on. I encourage you to maintain a sense of balance. Integrate testing as an essential part of your development mentality and process - but don’t get carried away.

Do what you need first, then gradually build over time. With time and experience, you’ll find a natural level that suits both you and your specific project.

Over to you

So I’ve told my story and hope I’ve convinced you why testing won’t cost, but will save you time, stress and money. Tell me your story. What is it like in your organisation, your team, your job? Is testing taken seriously, is it integral to the development process, how much time does it save you. Share your thoughts in the comments.

Need Help?

If you’re new to testing, unsure about how to get started or the best approach to take, email me today. Better yet, Skype me. I want to help you integrate testing in to your applications, so that you’ll see the same productivity gains that I have. You won’t know yourself when you do.

image credit: thefangmonster