Quality Assurance & Testing
The Psychology and Practice of Shift-Left Testing
Quality cannot be built into software after the fact. In traditional development environments, code is written first, after which a separate QA (Quality Assurance) team performs manual tests for weeks before a release. This invariably leads to an endless cycle of bug reports, context switching, and delayed deliveries. The modern IT industry solves this by ‘shifting left’ testing in the lifecycle: testing before or immediately during the writing of the code. Test-Driven Development (TDD) and automated End-to-End (E2E) testing are the pillars of this process.
TDD is not merely a testing strategy; it is primarily a software design strategy. It forces developers to think about the architecture and requirements of their code before they write even a single line of logic.
The Red-Green-Refactor Cycle of TDD
Test-Driven Development is built on a strict, repetitive cycle known as Red-Green-Refactor:
- Red: The developer first writes a unit test (often with Jest or JUnit) for a very small functionality that does not yet exist. Naturally, this test fails immediately (code is red).
- Green: The developer then writes the simplest, rudimentary code to make the test pass (green). It is okay if this code is ugly or hardcoded; the only goal is for the test to pass.
- Refactor: Because the code is now backed by a test, the developer can confidently restructure (refactor) the ugly code into robust, optimized code, knowing that the test will fail immediately if the functionality unexpectedly breaks.
This process prevents over-engineering, guarantees 100% test coverage for business logic, and results in modules that are inherently testable and therefore decoupled.
The Pyramid of Testing and the Evolution of E2E
A sound test strategy follows the Test Pyramid: a broad base of thousands of fast, isolated Unit Tests, a smaller layer of Integration Tests (which check whether modules work together with, for example, the database), and a narrow top of End-to-End (E2E) tests. E2E tests emulate a real user clicking in a browser and check whether the entire system works correctly from front-to-back.
For years, E2E testing was the Achilles’ heel of development teams due to fragile, agonizingly slow test suites powered by Selenium. Today, modern tools such as Cypress and, even more impressively, Microsoft Playwright dominate the market. Playwright communicates directly over the Chrome DevTools Protocol, resulting in unprecedented speed. It supports parallel test execution, multi-browser testing (Chromium, WebKit, Firefox) out of the box, and has built-in ‘auto-wait’ functionality, which remedies the notorious problem of tests crashing because the UI loaded just a little too slowly.
Automation in the CI/CD Pipeline
A test suite is worthless if it is not executed consistently. Therefore, Unit, Integration, and E2E tests must be an integral part of the CI/CD pipeline (e.g., GitHub Actions or GitLab CI). When a developer submits a Pull Request, all tests are automatically triggered in a headless browser in the cloud. If even one test fails, the version control system refuses to merge the code. By investing in TDD and advanced tools such as Playwright, you create a fearless development culture in which developers can confidently push dozens of complex changes to production daily. You can find more about quality control at AG Connect.
Next: Svelte and SvelteKit: Why Compile-Time Reactivity Beats the Virtual DOM
