3 ms·

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

by izacus 4y ago

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.

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

by izacus 4y ago

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

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.