. NET Core TDD prequel: Writing code that is easy to test--dependencies

1th: How to create a "seam". Seam (seam) is a concept that needs to be known.

2nd, avoid writing hard-to-test code when building objects.

This article is the 3rd chapter, which describes the dependencies and Dimitri laws.

Dimitri (Law of Demeter)

Or use the example of building a car. When producing a car, you need a tyre, what type of tyre is needed to assemble it, the tyre is requested, and the person concerned will send the tyre from the warehouse to the production line for assembly.

I believe very few car factories will do this: when the car is being produced, the car assembler takes the key to the storeroom and goes to the storeroom to find the required model from various tires.

This is an example of a violation of the Dimitri law.

The Dimitri rule probably means: "Just access the object you created, or pass it as a parameter to your object." Do not access objects indirectly through other objects "

In one sentence, the Dimitri rule is: " just talk to a direct friend and don't talk to strangers ."

Note: The Dimitri rule is not strictly a law, it is only a very useful guiding principle.

Problems that exist

The above example is described in code:

This violates the Dimitri rule and causes the following problems:

• resulting in tight coupling between the Benzcar and the warehouse and the Michelintire, and in fact the Benzcar only need michelintire.
• When testing, Setup can be cumbersome . The code warehouse is a direct friend, Michelintire is a stranger. We need to set up test doubles for both warehouse and Michelintire.
• the dependencies that are really needed are not explicitly defined in the constructor . Here warehouse is equivalent to a container, when testing, we may not know what to do for the warehouse in the test doubles.

Danger Signal

The following notation may mean that your code violates the Dimitri rule:

• There is a call in the code: "warehouse.getTire.getMichelinTire", with a series of dots ".". But sometimes it is possible to do so, for example in fluent (Fluent) Form builder mode, because the fluent interface usually returns the object itself and then uses the object.
• depends on the container . For example, use Ioccontainer as a dependency injection.
• the names of the dependencies are Xxxcontext, Xxxcontainer, Xxxenvironment, Xxxmanager, Xxxservicelocator.
• you need to create a mock object that returns mocks when you test .
• the settings at the time of the test are very cumbersome .

Solutions

The solution is to obey the Dimitri law.

just inject the dependencies that we need directly, and use them directly. This will ensure that the dependencies are clear, and at a glance you can see which objects are dependent on the test .

Example code example One

The following violation of the Dimitri Law, directly injected is the warehouse, and the actual use is Michelintire:

The correct approach is to inject the directly used dependencies:

Example Two

The following code also violates the Dimitri rule, which injects an object from a container class:

This servicelocator is equivalent to a container. In this case, the person writing the test may not know which object to use in the container at all.

You might say it's flexible (I used to do that too), but when it comes to refactoring, it's easy to make a mistake here because it doesn't really look at which object it depends on.

The right thing to do is to inject the directly needed dependencies:

The law of Demeter related content simply describes these.

. NET Core TDD prequel: Writing code that is easy to test--dependencies