On The Daily WTF was a nice story: Unit Tested. It’s a story how someone tried developers to test their code and failed.
It’s always the same story and always the same reason: For a change in behavior, expect a year for it to become a habit. Under the best conditions.
So how do you introduce tests to developers? Here are some tips:
1. When they fix a bug, ask “Are you sure the fix is good? How do you know? Ah, you ran the code? Good. Then run the code once more but from a little test.”
2. When they discuss a new feature and can’t decide which way to go, say “How about you write a test for the feature and then try to modify the code so it makes the test pass. This way, we’ll see quickly which way works better”
3. Write some tests yourself. Make sure they run and if they fail, talk to the guy who made them fail. Help them to fix the problem. The bad solution would be to ridicule them, or punish them. Everyone makes mistakes. The tests are there to help to make less mistakes.
If the tests become another problem in the daily routine, They won’t generate enough positive energy for anyone to bother. Result: Failure.
If you meet resistance, ask yourself: What problem do I solve? Or am I just being religious? Do I test for the sake of testing? Or do the tests make everything better for everyone? Do they reduce stress or increase stress? Why?
All these questions will have different answers depending on your specific situation and the answers will help you to find your solution. Paper can’t think, you can. If some rule (out of a book or from your boss) just doesn’t make sense, then it’s your turn to come up with a solution.
There is just one thing to keep in mind and that’s the goal: Tests must help. Everything else will follow.
[…] long to change? 9. March, 2010 at 22:09 | In Philosophy | Leave a Comment Tags: Change My last post about making software developers properly test their code lead me to thinking about change. We all changed since we were born and not only in size. We […]