In the world where everyone wants something yesterday, it's very easy not to write any test plans, particularly when you got an eager client on your back.
And if you are severely behind schedule, and working all the hours god sends to deliver the work, you are going to have to cut corners and unit testing is going to be one of those things to set aside.
And why not? The client isn't going to applaud you on your well written test plans. They are going to judge you on the software you deliver and how well it performs.
But, it's going to be well written test plans that you will allow you to deliver an application that everyone can be proud off.
Traditionally, developers would code the application and write tests at the end if they had time. Which normally they didn't. But attitudes have changed and Test Driven Development is being rolled out a lot more in software companies across the globe.
So what is Test Driven Development?
You have a set of requirements for your software, but rather than coding these requirements into your software, you write specific test cases for these requirements.
These test cases will fail when you first write them. Of course they will. You haven't written the code to make them pass yet. The next job is to do that.
Once the code is written and the tests pass, it's onto the next requirement. And so on...
An Example
We don't want a customer to use a short and silly password like 1234. Because you know they will. So one of the requirements might be that the password must be 8 or more characters.
In the below example, we've used our favourite TDD package XUnit, and created a unit test for the length of the password using a IsPasswordValid function which will reside in the Customer class.
To prevent a error when compiling, we have already created the IsPasswordValid function in the Customer class, but have returned a NotImplementedException. This will ensure the test will fail.
// Customer.cs
public partial class Customer {
public virtual string Password { get; set; }
public virtual bool IsPasswordValid()
{
throw new NotImplementedException();
}
}
// CustomerPasswordTest.cs
public class CustomerPasswordTest {
[Fact]
public void PasswordLength() {
var customer = new Customer();
customer.Password = "TheBeast";
Assert.True(customer.IsPasswordValid());
customer.Password = "324i";
Assert.False(customer.IsPasswordValid());
}
}
As you would of guessed, the next task is to code the IsPasswordValid function in the Customer class, in-conjunction with the Password property. We need to ensure that it returns true if the password length is greater or equal to eight characters.
Once done, run your test and it should pass with flying colours.
And repeat...
This is great, what programs can I use?
Well I'm a Microsoft man, and the main choices are XUnit, NUnit or MSTest. People will debate on which one is the best and which one is the most efficient, but that's a debate for another time...
Conclusion
No need to worry about test plans holding you back at the end of a project, as they are already written. And you know they have already passed, so you know your software is going to be awesome.