Integration tests make unit tests absolutely redundant.

yakshaving_jgt 6 days ago | parent | next [-]

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 6 days ago | parent [-]

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 6 days ago | parent [-]

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 6 days ago | parent [-]

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 6 days ago | parent [-]

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.

▲

s_ting765 5 days ago | parent [-]

> 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?

You already said so in your first argument: Unit tests are cheaper and better(than integrated tests I presume).

Am simply following your behavior pattern here.

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

This is nonsense. A standard parser takes one input and does processing of this data to give an expected output. An integration test checks the parser does this one objective correctly. You have boiled down the 5 unit tests that don't test for anything *real into 1 integrated test that objectively gives better test data.

*code is not real until it does some business logic!

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

Maybe try to froth less when reading my comments, your brain might have some capacity left to understand comparitive adjectives.

	▲	yakshaving_jgt 5 days ago \| parent [-]
		> This is nonsense. A standard parser takes one input and does processing of this data to give an expected output. This appears to be the root of your confusion. Here's a good example of a parser: https://entropicthoughts.com/parser-combinators-parsing-for-... There are at least 16 paths through this function. Not one. 16.

▲

integralid 6 days ago | parent | prev [-]

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 6 days ago | parent [-]

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 6 days ago \| parent [-]
		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.