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

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