Loading…
The Hardest Part of Writing Tests is Getting Started
2023-10-18
- Source
- Shopify
- Published
- Added to Yomu
Summary
The article presents getting started with automated testing as the main obstacle, especially when a full suite requires helper tools, stubs, and fixtures that can overwhelm beginners. It argues that tests serve as executable documentation, preserve intended behavior and edge cases, and expose regressions before changes reach production. The recommended progression is to install a framework and verify both passing and failing tests, cover isolated functions, add stubs with sanitized API-response fixtures, and then build end-to-end tests while monitoring coverage. In an ETL example, API stubbing avoided expensive, slow calls, while database checks validated loaded and transformed data; the resulting tests covered more than 80 percent of the codebase and saved time for the author and team. The article also proposes E2E tests as a way to safely approach legacy code before refactoring it.
Context
Beginning a testing practice can be intimidating because complete test suites involve complicated helper tools, stubs, and fixtures. The article also addresses the risk of introducing regressions while changing legacy code and the desire to test an ETL system without relying on expensive, limited external API calls.
Approach / What changed
Start by installing the test suite and verifying that a simple test can both pass and fail. Then test isolated functions, use stubs and sanitized API-response fixtures to control dependencies, and add end-to-end tests that check transformations, database loading, and code coverage. For legacy code, create E2E tests before refactoring.
Takeaways
- A first test should be checked in both passing and failing states to verify that the test suite is functioning correctly.
- Stubs isolate the code under test from external libraries and APIs; saved API responses become fixtures, provided they contain no sensitive data.
- In an ETL system, stubbing expensive API calls and testing database results produced more than 80 percent code coverage and saved time for the author and team.