Motivating unit testing with a reduction in functional testing
Thursday, June 21st, 2012 | Programming
The problem with unit testing is that developers don’t want to write them. No surprise, there, they aren’t the most exciting thing in the world, unless you’re actually a tester and they are your pride and joy.
So, the challenge for creating a good development and testing cycle is how to ensure your developers are motivated to actually write the unit tests. Test driven development is a good way to go about this, and helps stop developers over-engineering too, but it requires a radical shift in your workflow.
Perhaps a less extreme modification, and one developers are more likely to buy into is to replace functional testing with unit testing.
Back in the old days, when you were working on a web application for example, you would write some code, you would then load it up in your browser and see if it worked. If it did you would move onto the next thing and if it didn’t you would go back and fix it.
Then the rise of unit testing for web applications came along and developers were asked to write the code, functionality test it and then write a unit test for it. But none of them did because they didn’t want to write a boring unit test.
However, recently I was writing a model for a web application. Having made my changes, I then wrote a new test for it in our set of unit tests to ensure that it worked as it should. I ran the tests, and I did. But, being pressed for time, I never actually ran a functional test on it. But it worked. Which is no huge surprise, given it passed the unit test.
But what if that was policy? All you had to do was to write the unit test and for it to pass that, you didn’t have to do a functional test. Developers might buy into that, because it takes roughly the same time (probably a little more, but not too much to worry about) and you don’t lose too much. Here is why:
You can’t get away from functional testing. At some point, someone is going to have to do a functional test and at that point they will see if it works or not, and knock anything that doesn’t work back to the developers. This isn’t the case for unit tests – you can go without them, it just means you end up producing pretty rubbish unreliable code and end up spending ages tracing issues down later. But it isn’t an in your face blocker, so developers often ignore it.
Of course, I wouldn’t recommend this for organisations who already have a testing culture embedded. But for organisations that don’t currently unit test, relaxing your rules on functional testing could help you take that first step down the road.
The problem with unit testing is that developers don’t want to write them. No surprise, there, they aren’t the most exciting thing in the world, unless you’re actually a tester and they are your pride and joy.
So, the challenge for creating a good development and testing cycle is how to ensure your developers are motivated to actually write the unit tests. Test driven development is a good way to go about this, and helps stop developers over-engineering too, but it requires a radical shift in your workflow.
Perhaps a less extreme modification, and one developers are more likely to buy into is to replace functional testing with unit testing.
Back in the old days, when you were working on a web application for example, you would write some code, you would then load it up in your browser and see if it worked. If it did you would move onto the next thing and if it didn’t you would go back and fix it.
Then the rise of unit testing for web applications came along and developers were asked to write the code, functionality test it and then write a unit test for it. But none of them did because they didn’t want to write a boring unit test.
However, recently I was writing a model for a web application. Having made my changes, I then wrote a new test for it in our set of unit tests to ensure that it worked as it should. I ran the tests, and I did. But, being pressed for time, I never actually ran a functional test on it. But it worked. Which is no huge surprise, given it passed the unit test.
But what if that was policy? All you had to do was to write the unit test and for it to pass that, you didn’t have to do a functional test. Developers might buy into that, because it takes roughly the same time (probably a little more, but not too much to worry about) and you don’t lose too much. Here is why:
You can’t get away from functional testing. At some point, someone is going to have to do a functional test and at that point they will see if it works or not, and knock anything that doesn’t work back to the developers. This isn’t the case for unit tests – you can go without them, it just means you end up producing pretty rubbish unreliable code and end up spending ages tracing issues down later. But it isn’t an in your face blocker, so developers often ignore it.
Of course, I wouldn’t recommend this for organisations who already have a testing culture embedded. But for organisations that don’t currently unit test, relaxing your rules on functional testing could help you take that first step down the road.