An Intro To Continuous Integration Testing
What it is, why use it and how to test
Constant integration means building your software whenever a developer pushes code. This affects your testing and requires careful planning and the use of test automation.
Introduction
Constant integration testing(CI) is the process of building a brand new version of your software each time you push a change. Clearly, CI has a big effect on testing, as it means you’re not testing stable applications. On the flip side, the changes you are analysing are considerably smaller. This means you’ve got to adopt a different approach to analysing than was traditionally the case. In this blog, we’ll explore CI and look at the challenges it generates for testers.
CI is not new, but it indicated a change from the traditional way of building software. To do CI nicely requires careful coordination and buy-in from both the developers and testers.
Once on a time, programmers would work individually and in groups on developing their portion of the program. Every few weeks they would upload all their new code to the server, along with the code out of all other teams. The next point was to attempt to solve all of the merge conflicts. Then you can run your build, at which point large quantities of errors probably showed up. Last, you would have a working build, ready to pass to the testers.
It does not take a genius to see the flaws in this approach. Several tricks were used to attempt to enhance this process. For instance, large pieces of software would be broken into small modules and treated as black boxes. As long as the interface worked, you removed the inter-dependencies. But, that can only go a brief way to solving the matter. And therefore we come to constant integration.
What precisely is CI?
CI is not rocket science. So, the solution would be to merge smaller quantities of code! Martin Fowler (one of the writers of the Agile manifesto) describes CI as follows:
Continuous Integration testing is a software development practice where members of a group incorporate their work regularly, usually, each person integrates at least every day — leading to multiple integrations per day. Each integration is confirmed by an automatic construct (including evaluation ) to discover integration mistakes as quickly as possible. Many teams find that this strategy leads to reduced integration issues and enables a team to create cohesive software more rapidly.
CI is a necessity for constant deployment (that we discussed in a current site ). In continuous deployment, you release the recently built code to manufacturing as soon as it is ready. However, CI and CD are different from each other, and many companies only conduct CI.
Why is CI such a good approach?
CI is a powerful approach which may be applied in the majority of companies. CI will reap any size of staff, so let’s look at some of the major advantages.
Regular wil reduce merge conflicts. Anyone who has fought with git merge will know the annoyance of merge conflicts. Occasionally solving these is simple, but other times it needs major changes. At the least, it is a time sink.
Programmers benefit from quick feedback, particularly when it’s associated with an error they have to fix. Consequently, if you build and examine the code at least daily, the errors are likely to be in code that has just been committed. In other words, the programmer won’t have to reload say about code that she worked on weeks past.
Everybody is working on the most recent code base. This considerably lowers the probability of problems in complex pieces of software. It also means that developers can see what each other is doing considerably more readily.
Any adjustments to the back-end surroundings are instantly available for front-end developers to operate with. This removes a key source of problems for most developers.
The best way to design your testing to CI
True continuous integration would suggest that each construct gets completely analysed. But even with the ideal test automation program in the world, this just isn’t possible. Some tests take a while to operate, and not all tests are equally important. Let us have a look at both those issues.
A full set of tests covers everything from unit testing to full regression and UI testing. Thus, unit tests can be completed rapidly. By contrast, a complete set of regression tests can certainly take hours to finish. This is especially the case if you need to reset the system state between each evaluation (as is frequently the case). Often your programmers will push code several times a day. This means there isn’t time to run all the tests for every construct.
The comparative importance of tests
As you will know, not all tests are of equal worth. Some can be testing an obscure corner case, but some test the central functionality of your entire system. This variable may be used to prioritise your tests.
Evaluation prioritisation
By splitting your evaluations into three categories it is possible to streamline your CI testing. Firstly, every construct ought to be subjected to a full set of (suitable) unit tests along with a smoke test. A smoke test is designed to test the minimal necessary functionality of your system. It ought to show up the most fundamental issues but may miss some obscure ones. You need to design your smoke check to operate in a max of a few moments.
Each hour you can subject the newest build to a more thorough set of tests, so long as they will complete within the time you have. You should pick the tests that are of the highest importance.
