Don't break existing code!

As software developers working in a team, you use many tools that provide collaboration between the team members. One of these tools is Jenkins that provides continuous integration. You can configure your integration server in the way that starts a project build when a modification in the source control repository occurs. The build can either succeed or fail. For the latter case, it may happen because of many reasons one of which is breaking the existing code. What’s your guarantee that your modification or addition of code won’t break your code base?

The answer to this question is Unit Tests, they allow you to verify if your refactoring breaks the existing code or not. This is done by running the already implemented unit tests before committing your modification. As an example, consider modifying an existing module X, the modification consists of adding a new unit test case and modifying an existing class. To verify your modification, you run the new test case, if it passes, this then never means that your modification didn't break your code. In order to be sure of that, you have to run all the tests contained in module X and not just the new one, if they all pass, then you have a confirmation that your code is in a good state.

Running the tests has to be done manually. Unfortunately there is not an automatic way to do that as the case of commit when using a SCM software as Subversion—e.g if you commit out of date files, Subversion will prevent you from doing that and the commit will fail.

Finally, you have to be extremely careful when you reach the point of commit. Because you don’t have a tool that prevents you from committing when your code is broken, you have not to forget testing the entire module before doing that.