Liz Douglass

Archive for August 2009

Seeing the real thing

leave a comment »

About three weeks ago I moved onto a new project that has already been going for several months. My arrival on the team coincided with the team also physically moving into a bigger space in a different building about 10 minutes walk from where they were previously. However the users of one of the systems that we integrate with remained in the original location.

Last week Nick and I were pairing on two defects that were raised in QA in our application. Both of these were indirectly caused by some data coming from our fake test implementation of one of our integration points. Our aim was not to make our fake any more capable or complicated than we possibly needed it to be. However, we did need to modify our fake, both to avoid raising bugs, or fix them where they occurred.

A question arose about how the real implementation of the system that we are faking works. Nick called up the users of the real system and within 15 minutes we were back at the old building chatting with them.

The ability to quickly get in touch with real users and see exactly how they do their jobs is extremely beneficial for a project team. There is no description or diagram that can replace the context and ‘ah ha’ kind of understanding that you get when you see the real thing. I remember having the same kinds of experiences in past jobs that I’ve had when I was an aerospace engineer. Going down and seeing the relevant parts (or even similar parts) on the production line gives you tangible knowledge and recognition that no detailed “fancy” CAD simulation, or description, can.

Not being able to access real systems and users is one of the biggest challenges  facing any deivery team. Where you are not working in the same immediate space as the people involved (either directly or indirectly) with the team, you are immediately at a disadvantage. Lucky for us, our recent move was only a small one, and direct contact can still be maintained.

This need for ongoing contact is something that ThoughtWorks is very aware of when doing distributed agile projects – now I know why.

Advertisements

Written by lizdouglass

August 20, 2009 at 9:50 pm

Posted in Uncategorized

Tagged with

On mocking and Spring

with one comment

Two weeks ago I was pairing with Alex on some Java integration tests for an application that uses Spring for dependency injection. Whilst writing one of the tests we realised that we needed to mock some behaviour on one of our Spring configured classes. Instinctively the simplest way to do this would be to replace the bean in our application context with another one, but alas after some brief investigation we discovered this is not an option.We ended up using the same pattern that was already in use in our code base, and I’m sure it’s one that some people will be familiar with:

First up we extracted an interface from the class that whose behaviour we wanted to mock:

public interface FooRepository {
    Foo loadFor(XYZ xyz);
}

Next we created a new Application Context XML configuration file to use for the test and included the ‘real’ one from our application. We also defined a stub class that implemented our new interface. It also had the same id as the class that we wanted to mock behaviour for meaning that the pre-existing definition would be overridden:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans.xsd">
 <bean id="FooRepository" class="FooRepositoryStub"/>
 <import resource="applicationContext.xml"/>
</beans>

Now for the behaviour that we want in the test…. Singleton scoped Spring beans are loaded at start-up (unless you have lazy loading which we do not). Hence if we want to be able to define specific behaviour inside a test we can’t use on our stub implementation alone – rather we need to use the stub as a wrapper for a delegate:

public class FooRepositoryStub implements FooRepository {

    private FooRepository delegate;

    public Foo loadFor(XYZ xyz) {
        return delegate.loadFor(xyz);
    }

    public void setDelegate(FooRepository delegate) {
        this.delegate = delegate;
    }
}

The delegate can then be used to provide the mocking that we wanted all along:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "classpath:applicationContext-test.xml")

public class ValidationIntegrationTest {

    @Autowired
    private FooRepository FooRepository;
    private FooRepository FooRepositoryDelegate = mock(FooRepository.class);

    @Before
    public void initializeRepositoryDelegates() {
        ((FooRepositoryStub) FooRepository).setDelegate(FooRepositoryDelegate);
    }

    @Test
    public void shouldInvalidateXYZWhenTheABCRuleIsViolated() {
        XYZ xyz = givenSomeContext();
        andTheUserHoldsFoo(xyz);
        whenSomethingHappends(xyz);
        thenItShouldFailWithReasons(xyz, "XYZ failed because of the ABC rule was violated");
    }

    private void andTheUserHoldsFoo(XYZ xyz) {
        Foo foo = mock(Foo.class);
        when(FooRepositoryDelegate.loadFor(xyz)).thenReturn(foo);
    }
    ....
}

So, with only an interface, another ApplicationContext XML file, a stub and a mock, we can define the behaviour in the test that we wanted (phew)! I’ve used PicoContainer before and only just now realise how easy with had it in setting up tests. Of course there may be an easier way to do all this – and if you have one then I’d love to hear from you.

Written by lizdouglass

August 20, 2009 at 9:47 pm

Posted in Java

Tagged with , , ,