With the advancement of accessible Continuous Integration (CI) services and easy-to-write testing suites we can build more robust applications without sacrificing the valuable time you need to focus on the code that counts.
The CI pipeline
Continuous Integration refers to any pipeline of processes e.g. linting, building, testing, deploying, that runs automatically whenever you push code to your version control repository.
I’m a big advocate of using CI in any case possible, I’m even using CI for this article.
There are a wealth of options available for your CI infrastructure: from GitLab runners using Kubernetes, which can auto-scale when not in use, to free minutes of Bitbucket pipelines, or even CI-only services such as Jenkins, TravisCI or TeamCity. Many more still are available, each with their own pros and cons such as ease of use, cost and flexibility.
These tools allow you to get up and running in a short amount of time, with integrations with most common version control platforms as well as small configuration files that are easy to manage.
CI has grown a lot smarter over the past few years; showing full logs of what’s running and the ability to preserve artifacts for set periods of time to review the reports makes it easy to see what has gone wrong, allowing you to drill down, replicate the issue and fix it. With some tools such as Cypress, you’ll even be able to get a recording of the tests.
Testing with what you know
When your user opens an application to test it, they don’t send raw data to a specific function and see if it returns the right value like your unit tests do. They open their browser, scroll down, click the button and wait for a response, we can do this with integration testing. This is how our users will see the application, so why not automate some of this testing as well?
There has been a significant rise in the usage of end-to-end testing tools in recent years, due to the increasing ease of implementation. Cypress is a commonly used tool that automates interactions to simulate using the application as a user would in the browser, enabling testing of common workflows and sections of your application which affect others. This may seem familiar if you’ve used Selenium before, however, there are some significant differences including the target and test runner being in the same runtime. You can find out more in their docs, to help you decide if it suits your needs.
Everybody has access to the testing suite that they need, and this helps us all to develop better quality software which is more maintainable.
Having that personal quality assurance mechanism ready for you every time you commit another section of code is incredibly useful. While we still have to configure these tools and set them up ourselves for now, it’s a path of constant improvement which you’ll want to be on sooner rather than later.
