3 ms·
> Isn’t testing the physical generation of a pdf more aligned with “integration” test not unit testing? Testing the api that makes the pdf is ok, but testing li
by DSMan195276 4y ago
> Isn’t testing the physical generation of a pdf more aligned with “integration” test not unit testing? Testing the api that makes the pdf is ok, but testing like this post suggests, with bitwise comparison is integration testing, no?
The fact that it writes the PDF out to a file potentially makes it an integration test, but the rendering aspect I don't think so. The poster is not testing the integration of the tool with ghostscript, rather ghostscript is simply used as an oracle for verifying the result. The only thing actually tested is the original a4pdf API, but some way of verifying the resulting PDF was needed, which is what ghostscript accomplishes. Effectively it's no different from a fancy assertion.
- flandish 4y agoI reckon so. It could align nice with a mock fs, I suppose. But if differences in fs or architecture are crucial - the real proof is in the integration.
- kccqzy 4y agoI have a much more liberal view of what constitutes a unit test: everything that can be run inside a single container is a unit test. Writing files? Unit test. Using databases? As long as that database is started by the test fixture in the same container and destroyed along with the container, still a unit test. Of course, if your test needs a database the natural follow-up question is whether it can populate the database with data known at build time, or it needs to reach out to get some realistic looking data. Only the latter makes it an integration test.