How high level should be my unit-test?

Question

I have a program with many classes. I manage the DI with Guice, btw.

I wanted to write in-progress tests to my code (unit tests and higher level).

I have few questions\difficulties:

1. How high should my tests be?

   I know there is no "right\wrong" answer. If I write the test too high it might be difficult for me to simulate all test cases.

   If I write the tests too low, every class\structural re-factoring I'll do will break the tests and that would be very tedious to maintain.

   I guess the solution is combining both? Or is there any best-practice guideline?

2. How would you call tests that call the highest API of my code, when I use mocks only for out-of-process services (DB, Http service etc)? They are not unit-tests because I don't mock all dependencies?

3. What is the best practice to inject mock using Guice in PROD code? create a mainModule class for each test-class? but then if I want a different data from the mock for each test - then I'll have as many mainModule classes as many test cases?

I could add a concrete example, but I thought the question might be cleared in general.

Answer 1

As far as I understand you are covering both tester and developer role in your team, as a consequence the time at your disposal for the testing is very limited and the outcome has to be maximized.

In this case my suggestion is to identify the part of your software that can be considered the core library (or libraries) and write unit tests for all of the public methods, then you can write specific automated tests (someone calls them functional tests) for the verification/validation of the main features of the system.

Everyone of us, even if we have testers in our team, has to find a compromise but unit testing the core components is really important.

Answer 2

Generally speaking the advantages of Low-level tests outweigh High-levels due to many reasons e.g. Unit tests are:

1. Faster (executed in memory)
2. Isolated (In contrast with High-level test, easier to troubleshoot)
3. Reliable (no flaky test)

and I would say easier to maintain in long-term. Also it helps code read-ability a lot if written in the correct way. Hence Test-pyramid is recommended.

Testing Strategies in Microservice (page 7-17) can give answers to your 1st and specially 2nd questions.