Tell don't ask

27 Jul 2014

Tell don't ask we have all heard it. Yet it is one of the most violated principles. It is also one of the most important principles to follow if you want a design that is flexible to change.

I have often heard people say, "... but it makes Test driving very hard". I disagree - what it does is stop you from testing at too granular a level and focus on testing behaviours rather than interactions.

Enough postulating ... here is an example taken from my current work. You have an interface to an external system - you have nicely encapsulated it into your own class and throw an exception if, for example, there are infra level issues. Once the exception is raised - you let it percolate to the top and create an alert to inform operations.

The diagram below depicts a more usual approach I've seen:

Ask! not tell

Chances are that we test drove the Infra Service knowing that it needs to have all the right details required for us to raise the Alert. However, we are not testing that the right Alert is created because that is not the responsibility of the Infra Service. Hence we poke a few holes in the Infra Exception class and assert that the exception is created with the right details.

Once we move to implementing the A Service we have all the relevant details exposed from the exception so we retrieve these details and create the Alert. Interesting that the real behaviour here is:

create alert with the right details if there is an infra error

not

create exception with the right details if there is an infra error and then create alert from exception with the right details

Now lets looks at the alternative. Lets say we drove the test from the outside, i.e. A Service, and did not mock the Infra Service but instead mocked the External System API.

Tell! don't ask

We end up with a tell-don't-ask approach where we are testing that the right Alert is created when there is an infra error. We also end up with fewer interactions and a more flexible design. If for example we decided to encapsulate the external system some other way, our tests will not need to change.

Although testing at this level provides us with far less brittle tests, the disadvantage is that parts of the implementation is further way. On the other hand there are far fewer reasons why a test may break during refactoring.

Finding the right level to test is not a science. We need to take complexity of the unit-under-test into account. The rule of the thumb is that we should test from outside and mock external boundaries until the tests get too complex and only then get more granular for the more complex parts striving to maintain flexible tests and simple design.

Blogs relacionados

Get content like this straight to your inbox!

Software es nuestra pasión.

Somos Software Craftspeople. Construimos software bien elaborado para nuestros clientes, ayudamos a los/as desarrolladores/as a mejorar en su oficio a través de la formación, la orientación y la tutoría. Ayudamos a las empresas a mejorar en la distribución de software.

Contacto

3 Sutton Lane, planta 3
Londres, EC1M 5PU

Teléfono: +44 207 4902967

2 Mount Street
Manchester, M2 5WQ

Teléfono: +44 161 302 6795

Carrer de Pallars 99, planta 4, sala 41
Barcelona, 08018

Teléfono: +34 937 82 28 82

Correo electrónico: hello@codurance.es