Test Driven Development
I don’t think there’s any one out there who wouldn’t like a bug free production grade application – which is not going over budget to build.
Here’s how you can get there.
NO doubt a successful application needs a lot of well made decisions about design, architecture, life-cycle planning etc. They form the scaffolding to what you are building.
What’s also true is that most of the pain and tedium you experience in software development is during any development run. Missed milestone dates due to buggy code, improper business logic and half-baked sloppy implementation, UI imperfections, slow and lethargic responses – to name a few.
You don’t get to lay your eyes most of these problems if you are lucky. But every software has them and its the development team’s job to find and fix the bugs before the release is ready for the world. This is done through through and iterative testing, working at many levels, typically after the code is written.
The developer works on the bugs the testing team found repeats the cycle.
One of the most important thing that helps you move through the development stage quickly and considerably more stable code is the concept of Behavior Driven Development or Test Driven Development.
They differ slightly in how are practiced. But as you may notice both put Testing before Development.
Most of the testing we end up doing is automated through scripts describing what use case should and shouldn’t be permitted, how the app should behave in certain conditions etc.
The idea of BDD is to have these tests before the code is written to ascertain what that piece of code should or shouldn’t do. So now what ever code is written is to conform to that behavior.
This saves a good amount of time and confusion as the developer himself writes the tests and fixes the bugs without going round in circles. Any shortcomings in the logic can be easily identified as a missing or erroneous behavior, any bugs are immediately evident.
But then again, None of this is useful if the tests and the behavior are not comprehensive enough. We use ‘Test Coverage’ to what portion of the code is covered under the tests.