37 ms·

Integration tests make unit tests absolutely redundant.

integralid 1y ago
Integration tests are as old as unit tests, and both predate their names. When exactly were unit tests made redundant? I don't see the point of your quip without a trace of actual argument. I feel like I don't write enough tests, and when I do they're usually integration tests, but some things - algorithms, complex but pure functions, data structures - absolutely deserve their unit tests that can't be reasonably replaced by integration/e2e tests.
- s_ting765 1y ago
  Here's the argument backing up my claim. Unit tests don't matter when you have other types of testing like functional or integration testing that will tell you whether your code has the intended behavior and effect when run. In the above statement unit tests is also considered as code. That's where the redundancy comes from.
  - skydhash 1y ago
    Unit tests do matter, especially when the logic is somewhat complex or very defined (splitting money, parsing some message). So unless the specs change, you rarely have to modify the tests. So it helps more in a technical sense, catching developer mistakes. Just like qa tests on some small part of the car can spot defect early on. Integrated tests is more about ensuring what matters to Product. A car that refuses to start is worthless for most cases. But the engine light and a window that can’t open is not usually a dealbreaker. Unit tests can help pinpoint an issue or ensure that a specs is implemented. But that’s mostly relevant to the developer world. So for a proper DX, add unit tests to help pinpoint bugs faster, especially with code that doesn’t change as much and where knowledge can be lost.
yakshaving_jgt 1y ago
No they don’t. If you’re, for example, writing a web application, and you have an endpoint which parses some data from the request and then responds with the result of that computation, why the hell would you test the fine-grained behaviour of your parser by emulating HTTP requests against your server? Testing the parsing function in isolation is orders of magnitude cheaper.
- s_ting765 1y ago
  Cheaper to run tests does not mean better. And your example does not test for real world behavior therefore the test is lower quality by definition.
  - yakshaving_jgt 1y ago
    All else being equal, cheaper is absolutely better. How does my example not test real world behaviour? I mean, I didn’t even provide any code here so what exactly are you imagining?
    - s_ting765 1y ago
      Your example scenario avoided doing an end to end test for the data processing involving the parser instead opting for a unit test just for the parser. We have developer sandboxes for this purpose so you don't have to guess the structure of the data you will receive from the actual server. Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.
      - yakshaving_jgt 1y ago
        How do you know that? How do you know that I wouldn't write an integrated test which verifies that my parser is correctly integrated with my system? The point is, there is typically more than one path through the logic of a parser. The cheapest way to test these paths is in isolation. If there are five paths you care about, you could write six integrated tests — one for each of the five paths you care about, and one to verify that your parser is correctly integrated with your system, or of course you could write five isolated tests (which are cheaper to write and cheaper to execute) and one integrated test. So, five cheap tests and one more expensive test, or six more expensive tests. > Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper. …What? I'm sorry, this is near enough unintelligible.

Integration tests are as old as unit tests, and both predate their names. When exactly were unit tests made redundant? I don't see the point of your quip without a trace of actual argument. I feel like I don't write enough tests, and when I do they're usually integration tests, but some things - algorithms, complex but pure functions, data structures - absolutely deserve their unit tests that can't be reasonably replaced by integration/e2e tests.

s_ting765 1y ago
Here's the argument backing up my claim. Unit tests don't matter when you have other types of testing like functional or integration testing that will tell you whether your code has the intended behavior and effect when run. In the above statement unit tests is also considered as code. That's where the redundancy comes from.
- skydhash 1y ago
  Unit tests do matter, especially when the logic is somewhat complex or very defined (splitting money, parsing some message). So unless the specs change, you rarely have to modify the tests. So it helps more in a technical sense, catching developer mistakes. Just like qa tests on some small part of the car can spot defect early on. Integrated tests is more about ensuring what matters to Product. A car that refuses to start is worthless for most cases. But the engine light and a window that can’t open is not usually a dealbreaker. Unit tests can help pinpoint an issue or ensure that a specs is implemented. But that’s mostly relevant to the developer world. So for a proper DX, add unit tests to help pinpoint bugs faster, especially with code that doesn’t change as much and where knowledge can be lost.

yakshaving_jgt 1y ago

No they don’t. If you’re, for example, writing a web application, and you have an endpoint which parses some data from the request and then responds with the result of that computation, why the hell would you test the fine-grained behaviour of your parser by emulating HTTP requests against your server? Testing the parsing function in isolation is orders of magnitude cheaper.

s_ting765 1y ago
Cheaper to run tests does not mean better. And your example does not test for real world behavior therefore the test is lower quality by definition.
- yakshaving_jgt 1y ago
  All else being equal, cheaper is absolutely better. How does my example not test real world behaviour? I mean, I didn’t even provide any code here so what exactly are you imagining?
  - s_ting765 1y ago
    Your example scenario avoided doing an end to end test for the data processing involving the parser instead opting for a unit test just for the parser. We have developer sandboxes for this purpose so you don't have to guess the structure of the data you will receive from the actual server. Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper.
    - yakshaving_jgt 1y ago
      How do you know that? How do you know that I wouldn't write an integrated test which verifies that my parser is correctly integrated with my system? The point is, there is typically more than one path through the logic of a parser. The cheapest way to test these paths is in isolation. If there are five paths you care about, you could write six integrated tests — one for each of the five paths you care about, and one to verify that your parser is correctly integrated with your system, or of course you could write five isolated tests (which are cheaper to write and cheaper to execute) and one integrated test. So, five cheap tests and one more expensive test, or six more expensive tests. > Also if all else was equal between multiple types of test, there wouldn't be need for comparison ala cheaper. …What? I'm sorry, this is near enough unintelligible.