Our small team has made the curious observation that diagnosing and fixing broken automated tests is a useful activity; in particular, if the CI build indicates that developer A’s last check-in broke some tests, developer B can learn about (and possibly improve on) what developer A was doing by understanding why the test failed, and fixing it (either the code or the test, as appropriate.) This activity confers some of the benefits normally attributed to pair programming or code review, as far as getting more pairs of eyes on tricky pieces of code.
I’m wondering if other teams have made this same observation, and whether a practice like this makes sense to other people? Should the person who broke it, fix it, or should that job fall to co-workers?
11
So I was being flippant in my comment, but, that should be the case and not only that there should be a defined process for what happens and how long the build may remain broken for before the code just get rolled straight back out again.
- If a developer can not build the product before checking their code in, then the project is too big or not modular enough.
- If developer A changed the API and this broke the tests, the developer A should have seen that coming and it should have been flagged before making the changes.
- If the full suite of tests is huge and can only run over night, they should be broken down into smaller suites. Usually these would relate to the modules of your project and then further into unit and integration tests.
- You have CI which is great, is it set to poll your SCM for changes and run some tests on updates?
- How often is code being checked in, could it be that check ins are too large and you would benefit from more frequent check ins.
- Forking/Branching can be useful to manage different development streams if your developers are checking in unrelated changes that may break each others code in ways that they could not have anticipated.
- Whatever the process is it should be rare that B is fixing A’s code alone.
- Always be pragmatic.
I do not believe that spreading the fixes around (in this instance) is useful, you’d benefit more from pair programming around the problem areas in the first place. In essence be proactive not reactive. You can give all the low priority bugs to your new developers and get them familiar with the whole codebase 🙂
Regarding
and if no tests ever broke, the utility would be lost
That is silly. If what you are saying is that you lack sufficient code coverage to tell if a core function of the code has been subverted and that is why no tests are breaking then yes, they lack utility. The tests should of course break (and if you’re practicing TDD they should even start broken), but the point is that they should break (and be fixed, with or without cooperation between A and B) on the developers machine.
Years ago some bloke out of Eastenders wrote some things about it, but there are probably a million newer resources to cite.. Martin Fowler says.
Best thing would be when the team decides in consensus who should fix the broken tests, depending on the indivdual case. This may be sometimes A, sometimes another person B or both together. If B does it alone, it would be nice at least to inform A on how he fixed it. And if there is some kind of trap some other people of the team should be aware of, the one fixes the bug should inform them, too.