Great article Romario!! :)
I have a similar point of view, but I follow a different approach identifying my unit tests. The main point for me is what we have to consider as a unit to be tested (Kent Beck’s discussion about unit va integration tests). IMHO, a unit is a set of components that work together in order to accomplish a task when most of the time those components make no sense in isolation. Following this approach, I don’t need to mock the events that wire those components and I can focus in which interactions I want to cover (I follow an outside-in tdd approach based on user stories DoD).
Additionally, I would like to add that the feature approach for organising code it’s great, but I always try to think in all my client code, including components, tests, repositories, services or whatever is needed. In this scenario, I tend to prefer to organise my code in functional areas (business contexts like in DDD) and then arrange al my assets inside each context.
Thanks for sharing!!!
