test-driven-development

Start by agreeing the public interface and the seam the tests will observe, then list behaviors smallest-first. Write one failing test, watch it fail for the right reason, write the minimal code to pass, and refactor only while the suite is green.

Reproduce the bug with a failing test at the correct seam before fixing anything, and confirm the failure matches the reported symptom. Minimise the reproduction, fix the code until it passes, and keep the test permanently as a regression guard.

Yes, the workflow is framework-agnostic and does not assume a runner, assertion library, or mocking tool. It detects what the project already uses before the first cycle and asks which runner to target if nothing exists yet.

Skip the loop for pure renames, config and wiring with no independent source of truth, behavior provable only through real networks or browsers, and disposable exploratory spikes. In those cases name and run a substitute check such as a type check, smoke test, or manual reproduction instead.

Repeated failure to reach green means the step was too big. Revert to the last green commit, split the behavior into a smaller case that can pass in a few lines, and check whether the awkward test is pointing at an interface problem.