5 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 lik

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?

izacus 4y ago
Is naming these tests a seriously useful thing to bikeshed on?
- mardifoufs 4y ago
  Having well defined terms, and using them well, is essential to any type of engineering. I don't know why aiming for precise terminology is only controversial in software engineering.
- PaulStatezny 4y ago
  There is a distinct and meaningful difference between unit tests and integration tests. flandish is not bikeshedding. Unit tests are about testing a single unit in isolation. Integration tests are about testing the integration of multiple units. With unit tests, the industry's general attitude is that there should be no side effects, such as reading/writing to databases or the disk. Side effects are generally embraced for integration tests, on the other hand. As a result, unit tests are mostly useful for "pure" functions, ones where the output is 100% derived from the input, regardless of any state external to the function. (Such as database records.) However, a large portion of the industry hasn't realized this and so you get millions of lines of dependency-injected unit tests that really don't provide much value in terms of catching actual bugs. (If these tests were integration tests, they'd catch actual bugs 10x more often.) A unit test for generating a PDF will not actually involve writing a PDF for disk. An integration test, however, might. So as I said, this isn't bikeshedding. ;-)
- leni536 4y ago
  Well, the blog post could have just called it "test", and nobody would bikeshed it.
  - quectophoton 4y ago
    Yeah the blog author accidentally triggered one of the fundamental laws of internet: "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer." Also known as Poe's Law.
- flandish 4y ago
  …yes. Because different energy, documentation, and sometimes entire groups of people are on different phases. It’s not always a single 100x-elite-monster-drinking coder cranking out monoliths in a silo. I have a hard enough time with project management getting it wrong: - testing an api’s public methods is far “faster” than testing how files are made on diff procs or fstabs.. - that translates to silly gantt charts… You get the idea.
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 ago
  I 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 ago
  I 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.

izacus 4y ago

Is naming these tests a seriously useful thing to bikeshed on?

mardifoufs 4y ago
Having well defined terms, and using them well, is essential to any type of engineering. I don't know why aiming for precise terminology is only controversial in software engineering.
PaulStatezny 4y ago
There is a distinct and meaningful difference between unit tests and integration tests. flandish is not bikeshedding. Unit tests are about testing a single unit in isolation. Integration tests are about testing the integration of multiple units. With unit tests, the industry's general attitude is that there should be no side effects, such as reading/writing to databases or the disk. Side effects are generally embraced for integration tests, on the other hand. As a result, unit tests are mostly useful for "pure" functions, ones where the output is 100% derived from the input, regardless of any state external to the function. (Such as database records.) However, a large portion of the industry hasn't realized this and so you get millions of lines of dependency-injected unit tests that really don't provide much value in terms of catching actual bugs. (If these tests were integration tests, they'd catch actual bugs 10x more often.) A unit test for generating a PDF will not actually involve writing a PDF for disk. An integration test, however, might. So as I said, this isn't bikeshedding. ;-)
leni536 4y ago
Well, the blog post could have just called it "test", and nobody would bikeshed it.
- quectophoton 4y ago
  Yeah the blog author accidentally triggered one of the fundamental laws of internet: "The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer." Also known as Poe's Law.
flandish 4y ago
…yes. Because different energy, documentation, and sometimes entire groups of people are on different phases. It’s not always a single 100x-elite-monster-drinking coder cranking out monoliths in a silo. I have a hard enough time with project management getting it wrong: - testing an api’s public methods is far “faster” than testing how files are made on diff procs or fstabs.. - that translates to silly gantt charts… You get the idea.

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 ago
I 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 ago
I 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.