Most of the programmers don’t start their working project from scratch when they come to new work but instead, they may get an old bunch of legacy codebase. I have the experience to work on a project which I call “Enterprise Frankenstein”. Many years of development without any consideration about architecture, good practice, automative testings etc. Programmers came and left and each one brought something new. At the end, the project looks like a heap of attempts, ideas, struggling and solutions from different programmers. Dependencies copied directly into lib folder (no maven, no gradle), all code stored on SVN in only one trunk (branch).
During my work on this project several times I tried to write Unit tests at least to support what already works but always happened something that interrupted and this was not done successful, plus I did not have enough experience to do such things. As a team grows up it becomes difficult to checkout libs from SVN (imagine more than 200 Mb jar files) and organizes import (manually configure Build Path in Eclipse) I decide to make next steps:
1. Start use Maven for dependencies
2. Move to Git (I really like Git working flow)
Maven integration took around 2 weeks, main problems appeared to organize the order of import and searching for dependencies which are not in repository anymore, few jars we still adding from private maven repository. Migration to Git did not take too much time (I used Bitbucket as a repository). More time took teaching team how to use Git and explain Git Flow. I choose this one as it was very convenient for current project and team: https://www.youtube.com/watch?v=6LhTe8Mz6jM. Started from this point the project got new kind of activity: “Code Review”. Right now whenever someone want to publish changes from his branch he makes Pull Request and me can easily check which kind of changes person did and related to which Task (we using Jira to manage our tasks) and if he committing code which is not full worked or does not catch requirements I always can decline his Pull Request until he complete his task in right way.
All described before look like easy and must be implemented in each project but in reality, we always meet a lot of resistance from people who get used to work in an old way and don’t will to change. After finished migration, I started to think, how to deal with method’s logic if new programmers come and change it but don’t know all conditions (no documentation in the project). So really simple answer appeared in my head – Unit Tests to wrap existed method and notify me if someone broke working functionality and if tests were done in right way it may be even better than documentation.
How to start Unit test for this project I’ll describe in next posts.