Congratulations! You’re reading my very first post in this blog, for which I hope will be an interesting account of my adventures in XP.

Business Wiring – A Pattern?

I recently began designing a new system. After all my attempts at XP, this was going to be the best one, is what I told myself. So, I’m test-driving the whole thing. I’m driving individual services with ATDD/TDD cycles:

  1. Write an end-to-end test (I call them system tests)
  2. Watch it fail
  3. Write a unit test – which starts to define a component (a module within the service) – closest to the system’s periphery
  4. TDD the test & component
  5. Write another unit test further into the system
  6. TDD the test & the other (more internal) component
  7. Repeat until the system test passes
  8. Write another system test
  9. Repeat …

The system tests test the whole system (go figure), minus the adapters which should be mocked so the system test would be as fast as the unit tests.

That means the system tests need some wiring which will provide them with the system they test – a bunch of components wired together. I use a special wiring class for this.

I mentioned the adapters are excluded from the system test. This is explicitly visible in the wiring class: The adapters are injected through its constructor (how else?) and are stored as final fields. The class has no public methods. The injected adapters are both input and output adapters so the whole system is tested through them.

Now, the wiring class is not used just in system tests. It’s used in production as well – that way the system tests can test what they should: the correctness of the wiring – the integration of the components in the system.

I want to have this setup for every service. I’ll drive every one of them with system tests (followed by unit tests), so I will need a wiring class for my system tests to use. AFAIK, one wiring class per service is enough. If the class is too big, you have too much going on, and you probably need more services.

I don’t want to split my service wiring into sub-sections, because then I’ll again need an über-system-test which will need to have a wiring class for the wiring classes… Too complicated and unnecessary.

It seems to me that this would be a pattern – every service has a wiring class used as described above. A “Business Wiring” pattern, maybe? I thought of the “business” part because the components wired together are strictly business related. There are no adapters wired in the wiring class. The system tests don’t use ports or the file system. There are no database connections. Just business logic.

Practical Java recipe: Boot + Mockito

Boot it up!

When you’re making a Java (micro-)service, use Spring Boot – its very useful for a fast startup. Even without Boot, the Spring DI comes in handy to speed up your wiring.

But not the business wiring. Its prudent to keep your business stuff away from your frameworks. The business wiring will be taken care of in the Business Wiring class – one class for the whole service.

I set up my business wiring class so Spring can use it as one of its @Configuration classes. The adapters are injected in the @Autowired constructor. The service is provided by a @Bean method.

public class MyServiceWiring {

    public MyServiceWiring(
                InputAdapter input, 
                OutputAdapter output) {

        EntryPoint entryPoint =
                    new EntryPoint(
                        new Foo(
                            new Bar(output)));

        // Above is a dummy example of service wiring.
        // In principle, do wiring using output adapters,
        // yielding a component instance 'entryPoint',
        // which methods are directly called by the input adapter.

Notice the setter injection on the input adapter? This is the one exception in my “no setter injection” rule: Adapters are less important code and I’m willing to sacrifice their good design for the good design of the Business Wiring:
– constructor-inject all external stuff
– expose nothing: the system is a black box reachable only through its adapters

But what about system tests?

Its a bad idea to use Spring for our system tests because they are slow. The startup takes seconds. SECONDS. I need my tests to run in milliseconds. Because there’ll be lots of them. LOTS. Like 10^3. I’m prepared to wait a couple of seconds, but for the whole test suite to run, not one Spring test.

In short: Don’t use Spring to wire your system tests.

Shaken, not stirred

Since we have only one wiring class, we don’t need Spring – just instantiate it in the tests and use it to get a service instance.

There’s a bonus: Mockito can inject adapter mocks in our wiring class (constructor injection, remember?):

private InputAdapter input;

private OutputAdapter output;

private MyServiceWiring wiring;

This works! Mockito doesn’t mind Spring annotations, and Spring is not being used in tests. Which run like lightning, by the way.