Allan & Steve are the chubby founders of LessEverything. This is their blog, hear them rant, praise, give advice and talk about Just Stuff, Less Accounting, Lovd by Less, More Honey, Less Memories, Code, Business, Design, Marketing
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.
“From our perspective a buggy app is not done”
I don’t agree with that.
Sure, fixing things is meritous, but time and resources are limited.
And sometimes it’s better to practice triage with the least-critical bugs and move onto something else, instead of being a perfectionist.
@Joe Grossberg,
Thanks for your comment. I understand the need to triage bugs, I used to love bug-scrub meetings. But I don’t think it is being a perfectionist. Bugs that don’t need fixing are not bugs. Bugs that do need fixing should be fixed.
I think if you find your self triaging bugs you’re most likely paying for an earlier bad decision. Here are a few possibilities:
This list can go on and on.
Once these mistakes are made we must learn from them and not repeat them on the next project. If the end of every project is a nightmare of triaging bugs trying desparatly to convince the client that it is OK the way it is, then maybe one should hire someone else to manage the projects, or try carpentry.
When we launch a new project we always find a few bugs, usually two or three depending on the size of the project. We never have to triage. That is what writing tests buys for us.
(I’m not saying that you need a new profession, Joe, or that everyone of your projects ends badly, I just mean in general, if someone is in this situation.)
Also don’t overlook tests being insurance.
Any project has a personality, it grows, it evolves.
Do you buy a car without insurance ? Do you have cheap ass insurance for a luxury car ? Do you get to mortage sans insurance ?
Never build or develop for tomorrow, but to stand the test of times.
Discipline in testing is bullshit.
Continuous discipline, via regression testing as the application evolves, thats value, THATS discipline.
Tom, DIck AND Harry practices continuous discipline, that’s REAL value.
Discipline to write that INITIAL test for Rev. 7000, when you’re busy with commit 9000, that’s neither testing, not discipline.
Agree on the above that having to prioritize bugs being very much a side effect of earlier dodgy dev. practices.
Most importantly, it buys peace of mind to extend and refactor.
I’d love to take you up on a guest post regarding refactoring as billable hours, so much so that 1 to 2 days per week for a very large project is a good thing …