I was sent an email from a colleague asking about our testing philosophy and how we would get a developer to take a test driven development approach to writing code.
Here was his question:
Do you guys approach development with TDD/BDD?
If so, do you ever have any issues with developers slipping back into the ‘traditional’ modes of development? i.e. “Who needs these tests.. I’ll fix it if its broken”. Obviously, TDD is a concept where all involved really need to buy in – but it takes discipline. I was wondering if you guys simply run rcov now and again to check for coverage, review code periodically etc..
My response:
Everyone at Less breathes tests. We love them. In my experience the easiest way to make a developer fall in love with testing is to have them write tests on their own code. Assuming they know how to write tests, they will find bugs in their own code. Some mentoring may be required to teach proper testing.
If someone said to me “Who needs these tests. I’ll fix it if its broken”. I would reply, “It is broken right now. You just haven’t found the bugs yet.” If I was asked that question again I would start thinking that maybe that person isn’t such a good fit for Less.
If finding their own bugs wasn’t inspiring enough, I would start thinking that maybe that person isn’t such a good fit for Less. From our perspective a buggy app is not done, so we will keep fixing the bugs until the app is right. If your developer has already used up the budget writing the buggy code, then you, as the owner, are paying for the bug fixes. Writing tests either before, or while the code is being written ends up being faster and cheaper because when you ship you are done. Otherwise you can’t have a proper budget for a project and you are likely loosing out.
We use rcov to see if there is a test we are missing. There usually is one or two so we fill in the blanks. But we rarely get 100% coverage. 100% coverage feels good, but it does not mean the app is well tested, just well covered. Also, rcov only provides C0 coverage, so it can be fooled into reporting something is covered when it is not. (Does anyone know a C1 or C2 tool for Rails?)
Code reviewing is actually very hard to do well. I admit that I am not the best at doing code review, so we don’t use it a lot. Code review is very good for making sure the code is good in general terms. Checking for obvious things, are finders being scoped or is security being applied properly. But reviewing the code diff between revision 737 and 738 may be tricky enough that you approve something that has a new bug in it.
If you wanted it to build a product you’d find a way to get time to work on it. If you really wanted to start that new hobby you’d sacrifice something to find the time and money to do it.
I'll define a "Wannabe Entrepreneur" as someone who has never made money from their businesses. Here are the different types of wannabes.
In the past few years I've built go-carts, built a 200+ sq ft workshop, written several eBooks. How do I create a life where I have time to work on side projects?
Receive 5 Software projects mistakes we have made over the years and how to avoid them.