Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Our project have a lot of layers,
Entities
Repositories
UnitOfWorks
Domain Services (Business Logic)
Validation
Infrastructure
Application Services
etc..
We are only writing unit tests for Business Logic layer and mocking other parts. Is it possible and reasonable to do TDD in this case? (All Business Logic classes consuming other classes via DI with constructor injected dependencies)
We are only writing unit tests for Business Logic layer and mocking other parts. Is it possible and reasonable to do TDD in this case?
Yes, in fact that is highly recommended over the "unit test everything" attitude.
Remember, business logic is the interesting stuff that makes decisions. Everything else is just boring infrastructure code that wires up connections.
The boring infrastructure is easy to read but hard to test. The point of tests is to make code easy for humans to read. Boring easy to read code doesn't need unit tests.
This is why we don't unit tests GUI's. Instead we move all interesting logic out of the GUI and put it someplace testable.
The name for seperating hard to test code from interesting code is The Humble Object pattern1,2
TDD works best when you follow this pattern. It basically says if your code is interesting and hard to test then separate the interesting stuff from the hard to test stuff. That can be as simple as turning one function into two. One you unit test. One you don't.
Thinking you have to unit test everything in TDD is quick way to convince people that TDD doesn't work. No that's not what it's for.
Keep in mind there are many other kinds of tests besides unit tests. The slow ones are sometimes called integration tests. That's when you test what happens when you connect the things that TDD isolates. Those tests mostly just show that the connections work. These tests are slow. You don't run them often. Just be sure you run them at least once before you publish.
TDD is about the really fast tests. So fast you run them every time you compile. Some people run them on every keystroke.3 So please, don't confuse these two different kinds of tests and blame the resulting nightmare on TDD. That's not its fault.
Use TDD on what it's for: the interesting stuff.
Strictly speaking no.
TDD requires that everything you write has a test.
However, we all know that some tests are more useful that others. If you have complicated business rules and tests that validate your business rules match the spec then those are pretty useful tests.
If I come along as a new dev and break the database reading code then I probably can see its broken and know how to fix it. It would be nice to have a test but not essential.
If I break an obscure business rule edge case that was designed months or years ago, then I might not even notice anything is wrong without those unit tests.
Indeed, it's a very valid approach, as business complexity should be laying on the domain layer. Here, IMO TDD shines here as you don't have to do a lot of ceremony as you typically work with simple types - domain models , value objects, etc - and you can center yourself in modelling policies and behaviors.
I am personally not a big advocate of TDD'ing from the service layer. Here we should be having mostly orchestration code that calls to the domain and I/O adapters. The degree and quality of the patterns and abstractions used here might vary wildly between developers, and TDD'ing here means a certain degree of coupling to the implementation - you assume a sets of abstractions to be injected and knowledge of the services - which ossifies the code being tested and discourages its refactor further down the road. On the other hand, I can see TDD working from the controller, so you are only coupled to your application's external world contracts.
It's a very valid option though to do TDD from the service layer or controller itself on CRUDish apps, setting up a real database. Sure, test executions will be much slower but on this breed of apps you're typically writing a database wrapper so you cannot just assume certain behaviors of such a critical piece of your system.
