How to ensure code quality in Continuous Integration
When you work in big projects which designs critical tools, ensuring code and functional quality becomes top priority. In this post I describe an example on how we at Tieto setup development environments which tests and verifies code and functional quality.
The tools I use in this example is Gerrit/Git and Jenkins, which together will automatically test and deploy our code and binaries.
Gerrit is a code collaboration web that acts as a gate keeper for Git, which sets rules for what is needed for a commit to be pushed into Git as well as what a user is allowed to do. Code updates that gets pushed to Gerrit will require approved review score and a successful verification score. The review score is provided by other developers and/or architects.
The verification score is normally provided by an automatically triggered build job that starts all JUnit and Integration tests. Jenkins acts as the built trigger which starts all JUnit and Integration tests and when completed passes the results back to Gerrit. This is done through a Jenkins plugin called Gerrit Trigger which enables Jenkins to start executions based on Gerrit events. In this example we are interested in two different events. One for when a designer pushes in a code change which is called a patchset trigger. The other is when a change has been verified and merged into Git, which is called a merge trigger.
So looking at the picture above, what happens is that a user here pushes a change to Gerrit which creates a new patch set. This triggers a Jenkins job through the Patch set Trigger which will run all JUnit tests and Integration tests. The result gets posted back to Gerrit as a Verification score. When/if Gerrit receives both a positive review and verification score it is possible to merge the update to Git. This will create a merge trigger event which will trigger jobs that builds all binaries and then deploy them onto Nexus, ClearCase or any other distribution tool.
JUnit vs Integration tests
Looking at the previous sections I mention the concepts JUnit tests and Integration tests. In this section I describe the difference between the two.
JUnit tests is code that executes parts of the production code and verifies that it works as intended. An example of a JUnit test would be if we created a method that translate normal English to the robber language. A suitable JUnit test would be to execute that code and checks that the English has been translated correctly. In general JUnit tests are suppose to be very small tests which does not take long time to execute (seconds, not minutes). Together with JUnit setup it is also possible to get test coverage statistics. I personally use a plugin in my development environment I can recommend called EclEmma which will color mark code depending on if its part of the test coverage or not.
Integration test is something that tests your code in combination with external resources which simulates the usage of the application in environment that is as close as possible to the environment the application will run on. External resources used in a Integration test could be servers, web access, connected hardware. Here is an interesting article that describes the differences in more details.
Having the possibility of using JUnit tests together with Integration tests setup together with Gerrit and Jenkins is a great way of getting fast feedback about the quality of your code update. This also give us the possibility of doing quick through JUnit suites and doing manual Integration tests. Best thing is that all tools mentioned is free and open source so no extra costs are involved in using the tools and they are easy to setup.