4 ms·
In my experience a lot of engineers are stuck thinking in MVC terms an fail to write modular code. As a result most business logic is part of a request / respon
by philippta 3y ago
In my experience a lot of engineers are stuck thinking in MVC terms an fail to write modular code. As a result most business logic is part of a request / response flow. This makes it infeasible to even attempt to write tests first, thus leaving integration or e2e tests as the only remaining options.
- trwrto 3y agoWhere should the business logic rather be? My tests are typically calling APIs to test the business logic. Trying to improve myself here.
- philippta 3y agoThere aren‘t any hard rules here, but you can try to build your business logic as if it was a library, where your HTTP API is merely a interface to it.
- laurencerowe 3y agoI’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.