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 :)
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.