I'm currently the only TestInfected developer on this project; I think it shows in the code, which is very tightly coupled to the environment it runs in. In some cases, I've been able to take advantage of Java's NamingContexts to splice in a mock environment.
It's getting harder - foreign libraries are being introduced, without an insulating layer of interfaces.
The solution I'm exploring right now is mocking my test target.
Consider a class that looks something like [warning: uncompiled code
ahead]
class Target {
public void foo () {
// complicated stuff here
Result r = Library::Call(args);
// more complicated stuff
}
}
Where Library::Call, for whatever reason, puts too much drag
on the unit test to be practical (requires resources that take
too long to initialize, or something remote that isn't always
available, or data which is dynamic....)
So ExtractMethod like so
class Target {
public void foo () {
// complicated stuff here
Result r = callLibrary(args);
// more complicated stuff
}
protected Result callLibrary( Args args ) {
return Library::Call(args) ;
}
}
In an idea world, you would run your tests at this point. But
if we had tests, we wouldn't be up this particular creek.
Now, mock the target.
class MockTarget extends Target {
protected Result callLibrary( Args args ) {
return new Result(7) ;
}
}
Eventually, you'll want to take more permanent steps (adding an
abstraction layer in front of Library::Call, so that you can mock
the environment). But this trick may get you up and running more
quickly.
June 26, 2003 10:40 AM
| TrackBack