Topic: testing
-
Refactoring in small, verified steps
Refactoring changes structure without changing behaviour; doing it in tiny steps with tests green between steps, and separating refactoring commits from behaviour changes, keeps it safe and reviewable.
-
Property-based testing with generated inputs
Instead of hand-picked examples, a property-based test states an invariant and lets a library generate many inputs, shrinking failures to minimal counterexamples; Hypothesis is the reference implementation for Python.
-
Designing a continuous integration pipeline
A CI pipeline should be fast, self-testing and identical for every change: build from a clean checkout, run linters and tests in stages, fail loudly, and keep the total time short enough that people wait for it.
-
How much test coverage is enough for a small service?
Open question: for a service of a few thousand lines with a database and an HTTP API, what coverage level and test mix has been observed to keep defect rates acceptable without slowing change?
-
The test-driven development loop
Write a failing test, make it pass with the simplest change, then refactor with the tests green; the loop keeps design decisions small and gives every line a reason to exist.
-
Test doubles: stubs, mocks, fakes and when to use which
Test doubles replace a collaborator in a test; stubs return canned answers, fakes are working lightweight implementations, spies record calls and mocks verify expected interactions. Mocking everything couples tests to implementation.
-
Finding the commit that introduced a regression with git bisect
git bisect performs a binary search over history between a known-good and a known-bad commit; with an automated test script it finds the offending commit without manual inspection.
-
What code coverage does and does not tell you
Coverage reports which lines or branches executed during tests; it exposes untested code but says nothing about whether the executed code was checked. Use it to find gaps, not as a target.
-
Turning a bug report into a regression test
Before fixing a bug, reproduce it as a failing automated test that names the report; the test proves the fix and prevents the bug from returning.
-
The test pyramid and where each test belongs
The test pyramid recommends many fast unit tests, fewer integration tests and very few end-to-end tests; the shape follows from speed, isolation and diagnostic value, not from dogma.
-
Structuring a unit test: arrange, act, assert
Each unit test sets up one scenario, performs one action and checks one observable outcome; naming the scenario in the test name and keeping fixtures explicit makes failures self-explanatory.
-
Mutation score predicts a test suite's ability to catch defects
Hypothesis: the share of injected code mutations that a test suite detects is a better predictor of its defect-detection ability than line coverage; a proposed comparison against real escaped defects.
-
Diagnosing and removing flaky tests
A flaky test passes and fails without code changes; the usual causes are shared state, timing assumptions, order dependence and real external services. Quarantine, reproduce, fix the cause, never just retry.
Machine-readable: JSON