Refactoring business logic out to private methods and testing

Question

I am currently working on a project where there is a class ContactMonitoringJob a Quartz IJob class​ which in brief keeps pulling from a database and checks if any new changes have been introduced like a new contact being added or disabled for example, then generates "Actions" and persists them to the database for further processing later.

The main method in that class is Execute which after I found to be a bit beefy, I refactored by extracting multiple private methods in the class itself. Now coming to unit testing and since most of the specific/focused code is in multiple private methods, I am guessing they would not be tested individually but indirectly through testing the Execute method. And since the "Execute" method seems to be mostly orchestrating work by delegating to those methods and accessing services that interact with the database, I guess the tests on that method would be integration and not unit tests.

• Would there be any unit test at all in this case? If yes on what?
• If the only user for those private methods is the Execute method, do we still move those methods to one or more separate classes and thus unit test the now public methods?
• I am following the guidance that we unit test core domain logic and do integration tests on other pieces that interact with shared dependencies like the database
• Is it expected in similar cases if we extrapolate to the whole project that we have much more​ integration tests that unit tests?

https://gist.github.com/msd-sal/0704bd77f5c1de9afebbaf387af0cbdc

Thanks

Answer 1

I am guessing they would not be tested individually but indirectly through testing the Execute method. And since the "Execute" method seems to be mostly orchestrating work by delegating to those methods and accessing services that interact with the database, I guess the tests on that method would be integration and not unit tests.

If you mock the database and other services that Execute interacts with, then any tests exercising the ContactMonitoringJob class with the mocked dependencies is a proper unit test.

If you can cover in that way the private methods to a sufficient degree, then there is no need to refactor those further into public methods (of helper classes).

In addition to those unit tests, you would have a couple of integration tests that verify your class can also interact correctly with the real versions of the dependencies.

Is it expected in similar cases if we extrapolate to the whole project that we have much more​ integration tests that unit tests?

No. If you look at your tests from unit tests at the bottom, through integration tests to end-to-end tests at the top, and size each layer according to the number of tests you have, then it should roughly form a pyramid.

The largest number of tests should be unit tests, as those are typically fast to execute and easy to automate so you can run them often. Integration tests typically take longer to run per test, but there should also be fewer. The end-to-end tests at the top should be just a few. They often need to be executed manually and thereby take up a lot of developer/tester time.