I took this disappointment the way people often take it from their parents. Remember when as a child, one of the worst things you could feel was the disappointment of your parents. Well I guess that is how I felt.
I took over the engineering manager position of the unity team at the end of last year, and I tend to take criticism of the project and team personally.
So... why the guilty feeling?
Well, back around the time I took over managing the team, the general acceptance criteria for getting Canonical projects into Ubuntu changed. This includes Unity. There were a number of automated tests for Unity, and a series of distro acceptance tests that were manually executed. What we needed to do was to really change the team culture to one where tests were not only written, but expected. New features needed test coverage, bug fixes needed test coverage. The idea here, for all those that understand test driven development, and automated testing, was to make sure that bugs that were fixed, and new features, didn't get broken accidentally by new changes.
The guilt really came from knowing that I had allowed code reviews through the process without enforcing the need for tests. And that as a senior person on the team, others took a lead from what I did. If I was letting things through, so would others. This is where the feeling really came from.
It is very easy to land fixes to crashes quickly when under pressure. Especially when you've spent the last eight hours debugging in gdb, and auditing all the recently landed code looking for that change that would contribute to the broken behaviour that you have been trying to fix. When you finally find that one line fix, it is so tempting to just commit the one line. You know it works, you've just spent the last freaking eight hours looking at the weird behaviour. What you haven't done however, is stopped it from happening again, by encapsulating the behaviour in an automated test.
I plan to spend some of Monday going back and adding an automated test to cover the particular behaviour that we fixed the other day. I'll also write up what, and how this test gets written. Hopefully by writing this, not only will Unity get better test coverage, but I'll personally feel better knowing that I've done the right thing.
1 comment:
Writing tests takes a lot of discipline, and you're absolutely right about how tempting it is to land a 1 line fix without writing 50 lines of test.
One of the things that has helped me in the past is writing the test first, especially for a bug. This often helps you understand the bug better, and makes finding it easier, because you can identify when it happens and when it doesn't.
Writing test cases for new feature is where I have the hardest time. Since I don't usually know how I want the end feature to work precisely until I've finished writing it, I can't write the test code ahead of time.
Post a Comment