Continuous integration for automatic testing
Continuous integration (CI) testing is running your automatic test suite automatically every time someone proposes a change, instead of relying on a person to remember to run it by hand.
A CI server (GitHub Actions, GitLab CI, Jenkins, and similar tools all do this) watches a repository for new commits and pull requests. On every one, it checks out the code, installs dependencies, and runs the test suite from scratch, in a clean environment, the same way every time — unit tests, integration tests, and often the browser automation tests this site is about, all in one run. The result — pass or fail — is reported right on the pull request, before a human reviewer even opens it.
This is what makes automatic tests actually pay off. A test suite that only runs on one developer's laptop, when they remember to run it, catches far less than a suite that runs on every single change, automatically, and blocks the merge if it fails. CI is the mechanism that turns "we have tests" into "broken code cannot reach the main branch" — and it's usually the first piece of infrastructure a team adds once their browser automation tests are worth trusting.
Examples you can ask AI
- What does 'CI' actually mean, in plain terms, and why would a team bother running tests automatically instead of just running them themselves before pushing?
- I have a test suite that works locally — what's a simple way to get it running automatically on every pull request?
- My CI pipeline has gotten slow because it runs the full browser test suite on every commit — how do I restructure it to stay fast without losing confidence?