Post #2270885

2026-05-08 18:33 UTC

@phillmv@hachyderm.io @AT1ST@mstdn.ca @brib@bribstodon.xyz @jneen@unstable.systems One can’t write the tests without first writing the API, and it’s often impossible to figure that out without having first written much of both the code that implements the API and the code that uses it. For mature projects, test-driven development makes more sense.

Replies (1)

@phillmv@hachyderm.io 2026-05-08 18:50

@alwayscurious@infosec.exchange @AT1ST@mstdn.ca @brib@bribstodon.xyz @jneen@unstable.systems you can! you mock it out, and slowly replace the mocks as each piece comes online. "get /foo should return json '{bar:1}'" before its implemented `get /foo` will return an error – so we mock it out, and have our mock return an empty string. this way the you have a failing test that expresses your intent (as opposed to erroring out) once `get /foo` starts working, you delete the mock and now the same test targets the actual implementation, and if it passes you know you have working code. caveat being: writing these kinds of test mocks is very easy in Ruby and excrutiating in a lot of other languages. i don't always work this way but i find it helps me avoid analysis paralysis to think about the inputs and outputs

Open ##2270886