Wise Engineering
Published in

Wise Engineering

5 Tips for Getting More Out of Your Tests

Still from Ridley Scott’s Blade Runner

In vast majority of applications I have seen the domain logic is implemented using a set of Service classes (Transaction Scripts). Typically these scripts are based on tables in the DB. Entities are thin DTOs that have little or no logic.

The main benefit of this kind of architecture is that it is very simple and often good enough as a starting point. However, the problem is that over time when the application gets more complex this kind of approach does not scale too well. Often we end up with Services that call 6–8 other Services. Many of these Services have no clear responsibilities but are built in an ad-hoc manner as wrappers of existing Services adding tiny bits of logic needed for some specific new feature.

So how to dig ourselves out from this kind of architecture? One approach I have found very useful is looking at the unit tests when writing them. By listening to what our tests are trying to tell us we will be able to build much better design. This is nothing else but the “Driven” part in TDD which everybody knows but is still quite hard to understand.

Indeed it is relatively easy to write tests before production code but at the same time not let these tests have any effect on production code. Sometimes there is also this thinking that testing is supposed to be hard in which case it is particularly easy to ignore the “smells” coming from tests.

Following are some rules I try to follow when writing tests. I have found that these ideas help me to avoid fighting my tests. As a result not only are the tests better but also the production code.

In the following text I use “spec” to refer to a single test class/file.

Rule 1: when spec is more than 120 lines then split it

When the spec is too long we will not be able to grasp it quickly anymore. Specific number does not matter but I have found around 120 lines to be a good threshold for myself. With very large test file it gets hard to detect duplication/overlap when adding new test methods. Also it becomes harder to understand the behaviour being tested.

Rule 2: when test names have duplication it is often a sign that you should split the spec

Typically unit tests are 1:1 mapped to each production class. So tests often need to specify what exact part of the target class is being tested. This is especially common for the above mentioned Services which are often just collections of different kinds of procedures.

Lets say that we have a PaymentMethodService which has tests like:

These tests all repeat when gets payment methods. So maybe we can create a new spec for getting payment methods and we can just dump the duplicating prefix from all of the test names. Result will be:

Note that the spec name does not contain name of any production class. If I can find a good name that contains tested class I don’t mind but if it gets in the way then I’m willing to let go of the Ctrl+Shift+T. This aligns with the idea of Uncle Bob that test and production code evolve in different directions.

Rule 3: instead of splitting too long spec think if something should change in production code instead

If there are many tests for something then it means that the tested behaviour is complex. If something is complex then it should be split apart. Often lines of code are not good indicator for complexity as we can easily hide multiple branches/conditions into a single line.

From the previous example if we have multiple tests around the ordering of payment methods it may be a good sign that ordering should be extracted into a separate class like PaymentMethodOrder.

Rule 4: when test contains a lot of interactions then introduce some new concept in the production code

When looking at the tests for such Transaction Script Services then often they contain a lot of interactions. This makes writing tests very hard as it should be because there is clearly too much going on at once and we are better off splitting it.

Rule 5: extract new class when you find yourself wanting to stub out a method in tested class

When we think that we need to mock/stub some class partially then this is generally a bad idea. What the test is telling us is that we have too much behaviour cramped together.

We have 2 choices:

  • don’t mock it and use the production implementation
  • if our test becomes too complex or we need too many similar tests then extract that logic out into a separate class and test that part of behaviour separately

You can also check out my post from years ago for more tips for writing good unit tests.

P.S. Interested to join us? We’re hiring. Check out our open Engineering roles.

Originally published at https://tech.transferwise.com on March 26, 2017.




Posts from the @Wise Engineering Team

Recommended from Medium

This is a task given by Mr.

Lights, camera, TESTS!

Ilustración en la que un sujeto se ve a si mismo reflejado en una pantalla

CS 373 Fall 2020: Week 3

Free Mac Address Stalker And Best Stbemu 2022 UPDATED

Free Mac Address Stalker And Best Stbemu 2022 UPDATED


How I Organize My CSS for Websites Without a Framework

Haproxy Load Balancer Configuration Using Ansible

What are the merits of data compression?

Sana Paul, Nishtha Singh, Diksha Garg, Architects, Architecting, Architecture, Architectural, Design, Digital, Machine Learning, Artificial Intelligence, AI, Tech, Technology, Algorithmic Thinking, Algorithms, Cybernetics, Computing, Embodiment, Digital Landscape, IOT, Generative Design, Augmented Reality, Virtual Reality, AR, VR, Building Information Modelling, Analysis, BIM, Zeyka, Zeyka India

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ürgo Ringo

Ürgo Ringo

Have been creating software for 20 years. Last 7 years worked as IC and team lead at (Transfer)Wise. Currently working as VP of engineering at CleanKitchen.

More from Medium

Lessons learned from previous projects

Distributed Monolith

Object-Oriented Design Patterns

Clean Code Development | Integration Operation Separation Principle