Continuous integration

For those not knowing what those words means together:
https://en.wikipedia.org/wiki/Continuous_integration

Basically it's simply the fact that you have automated tests which will be run for you either when you commit your code to a repository or once every now and them by some trigger (like once a day).

After the tests runs you will get a report of how it went.

If your code is well covered by those automated tests then you should be somewhat sure that your last modification didn't break anything.

With the installation of TFS (Team Foundation Server) I started to dig more and more into this kind of development. Where I really dislike test driven development (I shall explain why on another post), I actually like the feeling of having tests checking the integrity of my code. I don't have the time to test my whole soft every time I change something, therefore having tests which even cover partially my code should ensure some sort of insurance against breaking changes.

In my case I have 2 sets of checks, one is "integration tests" that I made on all the modification functions of my back end and I have user interface automated tests to check the GUI part of the code.

The integration tests run every time I do a commit (sure it take some time, but as it doesn't block me in any way as they run on the TFS server, having them running all the time is not a bad thing), the UI tests are run once a day.

The main question is how much actually those tests will catch errors, and you may (or may not) be surprised that I first detected bugs while writing my tests, but as well I got quite a few reports of bugs afterward while I was working on some new feature. So yes all that costed me time but it increased significantly the quality of the software. Don't be fooled however, tests will not make your code bug free. They may tend to reduce bugs but will never show every possible bugs. Also there is a diminishing result the more tests you create. I mean, at first when you create your tests you will indeed catch more and more bugs, but while you reach 80% or more of the code coverage you will need more and more tests to actually discover fewer bugs. Even if you reach 100% of code coverage you will not actually discover 100% of the bugs. So don't loose yourself in such game.

When would you need to have such infrastructure like I set up myself? Well, if you write some prototypes you don't need any of those. However when you start developing for customers you should start to think about the quality as bugs are seen as something really negative by your customers. Try all your best to reduce the number of bugs and be prepared to deploy quickly "hot fixes" to fix any possible issue.

Having a "test instance" where you can deploy the work in progress and a "production instance" where the product is used by your customers will also ensure to give a chance to your customers to test the software before it's actually release. Even if they don't test it, you can always argue they could have done so.