Test whole application or parts of it? Or the other way round?

Question

I am writing a small-ish console application. I took care to be able to test the important business parts of it in Unit Tests.

But having most of it finished I realized I could just test the application as a whole. Basically, I could just test Main with the proper arguments so the application will "run through" all the parts I previously tested with specific tests.

Why would I write tests for smaller parts when I can test the whole thing? Wouldn't it be better to always test "from the outside" so to say? Meaning because the only "interface" for the user is the arguments and configuration, I should also only do tests from that angle.

An example to illustrate what I mean is when you consider a caluclator. That can be given a string to calculate.

Internall, it will use some parsing, do calculation and an output.

So, why would I write specific unit tests for the calculation part when I can write a test that just calls the calculator with a string with e.g. a simple addition.

By doing this, I will not only have tested the calculation itself, but also the parsing and I can even check if the output works as expected.

Or thinking the other way around: If I have already written tests for parsing, calculation, and output separately, should I even bother with writing another one that pulls all of it into account?

Because, when you add it all up, when you write small tests + tests for the whole thing, you basically duplicate each test. And that times the amount of actual tests you have to write. It seems a bit of a waste of time?

Answer 1

Why would I write tests for smaller parts when I can test the whole thing? Wouldn't it be better to always test "from the outside" so to say?

You have written your app, it all works. Great.

But you then want to make a change. You then run those "test the whole thing" tests and one of those tests fails. Somewhere in that mass of code, there is a mistake. Time to get out the debugger and try and trace where the problem lies.

If you have unit tests too though, that breaking change will likely be far more rapidly found by one of them failing too. That leads you directly to the source of the bug.

If I have already written tests for parsing, calculation, and output separately, should I even bother with writing another one that pulls all of it into account?

I can speak from bitter experience on this one. I unit tested my app to death. So I passed it over to QA, confident it was robust. They shredded it! Unit tests will only give you confidence that the parts work in isolation. When connected together though, other problems can occur. Those "unit interactions" also need testing.

So in summary, unit and end-to-end tests compliment each other. having both leads to a much better tested app and neither can truly replace the other. Stick to writing both.