Day: August 13, 2014

What happens when you have tests that need different resources with similar names?

Confusion, that’s what. Let’s map out a project so we can see what happens:

• Parent Project
  • Test Resources 1
  • Test Resources 2
  • Library Code (depends on both test resources projects)

Now, in our problem code, the resources for the test data use the same names, so the library code won’t be able to deterministically work out which set of data is being used.

How does one work around this?

The first, and probably best, solution is to use a different build tool, one that gives more finely-grained control over the build lifecycle: Gradle comes to mind.

The other solution involves a little more work, and probably would be classified as a Maven hack.

What you would do is fairly simple, but verbose; you’d add two more projects, as integrations for the library and the dependencies, like so:

• Parent project
  • Test Resources 1
  • Test Resources 2
  • Library Code
  • Integration Tests 1 (using Library Code and Test Resources 1)
  • Integration Tests 2 (using Library Code and Test Resources 2)

The problem with this kind of structure is that the Library Code project no longer has its own complete test structure; it can pass all of its own internal tests, without actually passing the integration tests, because those are in separate modules. Therefore, one might be tempted to write off failures in the integration test modules, and publish a flawed artifact to a central repository.

Again, the best approach is probably Gradle.

This morning, a user on ##java asked if private variables could be shadowed in subclasses.

Upon being asked to try it and see, the user said that they didn’t have the time, which was ironic (and wrong), but errr… what the heck, I’ll write a test case to demonstrate that no, shadowing private variables (and retaining their reference) was not workable: the superclass will use its own reference, not a subclass’.

So let’s see some code:

public class T {
    private boolean b=true;

    public void doSomething() {
        System.out.println(b);
    }

    public static void main(String[] args) {
        T t=new U();
        t.doSomething();
    }
}

class U extends T {
    private boolean b=false;
}

Upon execution, this outputs true.

Now, would this change if we used an accessor instead? Let’s add one to T:

public boolean getB() { return this.b;}

… and nope, nothing changes. The main point here is actually that shadowing fields like this (shadowing the actual field, not methods) is a Bad Idea, and doesn’t work, private or not. (If you change the visibility away from private, the result still doesn’t change.

What’s more, you generally don’t want to do it, and wouldn’t want to even if it were possible, because … what would be your point? You’d be effectively trying to change the semantic of the field, if you needed to do this – and this alters the superclass/subclass relationship in fundamentally unhealthy ways.

If you need a different value in the field you want to shadow, don’t shadow – just offer a protected mutator, and have the subclass set the value.