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?