I have a project that I have divided quite aggressively into different layers. I have
- REST Service (asp.net Web Api)
- Service Layer
- Data Layer
- Filters (extension methods on top of Data Layer)
- A number of Models and separate DTOs
- DbContext
What should I unit test?
Technically my REST Service points at my Service. So if I test my REST, I am also testing my Service.
Models, I don’t see how I can test these?
DBContext, is it necessary to test these?
If I test my Service I am testing my DataLayer
A good rule of thumb is anything containing business logic should be able to be unit tested. Ideally, all of your layers would be separated by interfaces and you should be able to inject mocked interfaces into the various layers. Anything that accesses an external component (disk, database, network, etc) should also be abstracted away. For example, in your data layer, the code that is responsible for opening the connection to the database, running a SQL statement, and closing the connection should be abstracted away. Then you can mock up the data access interface and the code you want to test, can be tested. In this example a data access layer method is mocked
As far as your models, if they contain only properties then it serves no purpose in testing them.
There are some instances where unit testing makes zero sense, such as creating a TCP server opening up listening point. Hopefully those are few and far between.