Post #2270886

@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