When developing an application in a team not everyone on this team will be equally good developers. Some will be skilled in some things and some in others and some not at all.As a team working in an agile process you usually have a definition of 'done' to follow. In our DoD it says never to merge code that is not documented and have proper tests. Sometimes though, a feature is so critical to some team member so the code has to be merged without tests. Sometimes a lazy developer might merge and call it a weekend.A merge like this means that when other team members pull the code, they will receive code that may or may not function properly and since there are no tests it is hard to verify. It can be very cumbersome to walk through that code to make sure it works before the team member can work on their task.It has happened on several occasions that the code that was committed without tests has been broken by other team members without them noticing.So my question becomes:How would you handle issues like this? Does it point to bad planning rather then bad behaviour?Who is to blame if code that lacks tests is broken?
How to handle committed and merged code that has no tests?
agile;testing;behavior
How would you handle issues like this?Take a look at continuous integration. When people commit, there should be an automatic build that runs the unit tests. This will catch regressions introduced in the new commit. It won't catch errors that have no tests - that will require changing behavior. Consider adding unit tests to your code review - if they don't exist, they don't commit.For a specific case, I'd probably revert the merge (if possible) and let them do it again once the issue is resolved. If the revert isn't possible, I'd have whoever pushed the commit drop everything until they fix what they committed. Remember, as long as the build is broken everyone is blocked.Does it point to bad planning rather then bad behaviour?Not exactly. It might be bad planning in that there's a rush to commit before something is done (it sounds like you define done as tested), but it's more likely having a definition of done that doesn't match your DoD (which is behavior).Who is to blame if code that lacks tests is broken?The person who committed the coded and whoever approved the untested commit (reviewers, technical leadership, etc).