4 ms·
I’m not a TDD purist but I’ve found that so long as the request / response flow is a JSON api or similar (as opposed to old style forms and html rendering) then
by laurencerowe 3y ago
I’m not a TDD purist but I’ve found that so long as the request / response flow is a JSON api or similar (as opposed to old style forms and html rendering) then writing integration tests first is quite easy so long as you make sure your test fixtures are fairly fast.
- _heimdall 3y agoWith this approach do you stop at testing the JSON API or do you still make it to testing the rendered HTML actually shown to the user? I've always actually likes the simplicity of testing HTML APIs in a frontend project. For me, tests get a lot more simple when I can verify the final HTML directly from the response and don't need to parse the JSON and run it through client-side rendering logic first.
- laurencerowe 3y agoWhile we had a few end to end browser tests they tended to be slow so the pattern we ended up at was to generate output from the API to use as mock data in the UI tests. I think it usually make sense to test the business logic at the JSON API level (except for particularly complicated parts where unit testing of that complex logic may make sense) and then use snapshot tests for the display logic.