Ricardo Borillo
Aug 22, 2017 · 1 min read

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!!!

)

    Ricardo Borillo

    Written by

    ♥️ Lean & Craftmanship @borillo @programmeratwk @startwarslab #agileatwork @devscola @decharlas @genbetadev