Quality in Software projects is important, as already elaborated upon in the previous post, it matters from day one. But as long as measuring and running quality metrics isn’t easy, it will be hard to follow through with quality.
For almost all programming languages there are tons of tools to run unit tests, check the code complexity or measure the code coverage. The easiest way to get these tools into your project is on day one. The longer you wait, the harder it gets to implement them. There will be dependencies which are not compatible, running the tests doesn’t work because you use a different folder structure and lots of other issues. The tools you choose to measure the quality will also influence the way you structure your project and your code. And I think this is good, as in most cases this leads to better structured code and less dependencies in the code which has lots of other advantages.
Setup and Build Tools
Installing the tools is not enough, it must also be easy to execute them and to get the metrics out. Otherwise, it is likely that you won’t use it and in case you share your project, others won’t use it. There are different tools out there such as Makefiles, Ant, Maven, Grunt and others, which allow you to automate running your tests or to get the code coverage. Pick the tool which is best for you and your project. For all tools, the execution should be just one command, such as make coverage in order to get the test coverage.
Not only running the tools must be automated, but also the setup of the tools. In case you have different dependencies in your project that are needed to build the test coverage, make sure that the setup of your project is also as simple as make setup. There are also lots of dependency managers out there that automate the installation of the dependencies for you, such as Bundler, Packagist or Pip. If you want to make it even nicer, make sure that your build script runs also make setup in case you run make coverage and some depenencies are missing …
To have these simple commands in place will make it very easy for you to run the quality metrics as often as possible. But also whenever new engineers join the project, with just one command they can start contributing to your project. If you don’t have these kind of scripts in place, you will spend a lot of time with every single engineer who joins the project. And in case some dependencies change, others don’t know how to get to the right setup again. This will not only cost you a lot of time, but it will also lead to frustration on all sides. To draw the analogy to building a car: Not having the script is like lending your car to someone else, but before the person is able to start driving, they either need a two-hour crash course from you or they need to read the full manual, because in your car, the accelerator is actually on the left side and the breaks are on the steering wheel. The next time the person will borrow your car, you changed the breaks to the left side and the whole process starts anew. If it is that hard to lend your car, you will not lend it to someone and the same is true for your code. If it is very hard for others to work with your code, you will not share it and they will not want to work with it.
Run it locally
It is crucial that all your quality measurements can be executed locally. How can you make sure your code is good enough if you can’t test it locally? When you have to commit your code to a build server first, which runs all the tasks and gives you feedback after several minutes / hours that you actually have one typo in a test, you will stop writing tests, since otherwise it will slow you down. In addition, I think “broken” code should never make it into a shared repository / branch, as otherwise you will not only break your own code, but everyone else’s, and your code will block the whole team. To draw the car analogy again: You implement a new break system in your car and also put it into the car the test team uses. After one week you realise that no test team is left, since all of them died in car accidents due to the breaks that didn’t work. You didn’t expect them to already use the breaks, since they were not finished / tested by yourself, but unfortunately they were testing the accelartor in the car which was ready for testing. Presumably your fellow engineers won’t die because of broken code, but frustration is guaranteed.
Make sure you and your team members can run all the metrics on your local machine and have it as close to the production system as possible. The best is to use a virtual environment with a clean setup. Tools such as Vagrant or Docker can make your life much easier. Do not run the code on your local machines, since normally every engineer has some special environment variables or tools installed on his computer. This can either get all the quality metrics to pass but then they fail on another system, or it can do the opposite. A simple example here is for all the engineers who develop on OS X. By default, OS X has a case insensitive file system. On the other hand, Linux, which most servers run on, does not. So in case you include the file image.png but it is actually called Image.png, it will probably work on your local machine but not on the production server. Run your code in a very simliar environment to the production in order to make sure it works. And again, make sure the setup of this virtual environment is automated so everyone in your team will use it.
Conclusion
In the optimal case, you would not even have to run your quality metrics. Instead, they would run every time you change your code and immediately give you direct feedback. There are tools such as watchr which are intended for continuous testing and which run the tests every time you change the code. Having feedback for your code as fast as possible is crucial in order to produce better code. Tests should not slow down your development but speed it up. Make sure that setting up your project and running your quality metrics is fully automated and that it happens as fast as possible. If your tests take a day to execute, no one will ever run the tests except your continuous integration system over night. This would mean the feedback cycle is one day long, which will make sure that you get a maximum of 365 feedbacks per year.