DI frameworks are painful!

This was a tough week and I am afraid that I don’t have any working code for you this week. I still have emotional scars from my attempts to configure dependency injection with Spring at work. After a lot of pain we eventually decided to use Google Guice and with it set up and running I don’t have too many problems adding to my framework. When I do mess it up however I find it very tough to debug.

As this project is intended to teach me, I am of course working code blind and building up from the ground up making each decision as I go along. After a week of playing around I managed to get a driver firing up and running, but as soon as I try to wire up the Page Objects it all goes pear shaped in a pile of construction exceptions.

I’ll go and study some more and then come back and see if I can get this thing going. Time for some resilience!

What is dependency injection anyway?

Starting out by applying the ‘Inversion of Control’ design pattern that I have best heard described as applying the Hollywood Principle. In other words ‘Don’t Call Us, We’ll Call You!’ Programming against interfaces means that we separate off what we want to happen, from how it is implemented.

This allows when running the code to define at that point what particular implementation you wish to use, perhaps a mock object, or a partially completed class. Whilst this can, and often is, performed by hand by a developer, there are a number of frameworks out there that will perform the role of finding implementations for you at runtime.

My goal is to configure Google Guice to do this for me. At this point in time:

Google Guice 1 : Alexander 0

JUnit 5 woes

I also made one of those learning mistakes at work this week. Having convinced myself in this Blog that I could safely get JUnit 5 combining parameterised and standard tests within a single class I saw an opportunity to fix a frustration I was having.

Running JUnit 4 tests in Gradle you have the useful option

test {
maxParallelForks = 4
  }

which will run up to 4 of your test classes in parallel. Unfortunately, there appears to be no way of controlling which classes are run in which fork and hence you cannot prevent a particular pair of a parameterised test and a non parameterised test from running in parallel.

Great I thought: Now I can mix different types of tests together within the class and ensure that they will not be run in parallel…

A few hours later, I had my tests switched over (I have been planning for this since the beginning so most of the groundwork was done.) The tests run beautifully: Great, so how do I set the parallel forks…….

always important to do your research and a little proof of concept before going too far in a refactoring. Lesson learnt.

Talking of work. We are getting enticingly close to the release of V1.0 at the office, so time and energy for coding at home are running thin.

Apologies for the lateness of this one. I’d better get started on preparing for my next post.

Progress made:

• Managed to get my DriverFactory launching with Guice, but little further.

Lessons learnt:

• I need to go back to the drawing board and plan for my next attempt at getting DI running.
• The JUnit 5 runner for Gradle does not support parallel running at present.
• ALWAYS use a proof of concept before going too far with refactoring.