Suppose you have a class that accesses a property (perhaps, it’s a GUI class)
How do you test it in Java?
- You can inject (and mock) a
ResourceBundle
import javax.swing.JLabel;
import java.util.ResourceBundle;
// simplistic example
public class GreetingPanel extends JPanel {
private ResourceBundle bundle;
public GreetingPanel(ResourceBundle bundle) {
this.bundle = bundle;
add(new JLabel(bundle.getString("greeting)));
}
}
Pro: Exposing and mocking dependencies is a “golden standard” in unit testing
Con: One more dependency in your constructor. If you already have a lot of them, it may be a concern
- You can set up test properties. Probably, you’ll just copy an existing list to avoid extra work
Pro: You don’t need to add another argument in your constructor
Con: You’ll probably have to manually synchronize the two property lists in case keys are removed/added. It may make your tests fragile. Even if you don’t care about values (you test logic), you’ll have to keep the property list up-to-date so that your tests don’t fail due to missing keys
- (I believe it’s the best way) Write and use
DefaultableResourceBundleinstead
import javax.swing.JLabel;
import java.util.ResourceBundle;
// simplistic example
public class GreetingPanel extends JPanel {
private ResourceBundle bundle;
public GreetingPanel() {
ResourceBundle wrappedBundle = ResourceBundle.getBundle("application");
this.bundle = DefaultableResourceBundle.of(wrappedBundle, key -> key);
add(new JLabel(bundle.getString("greeting)));
}
}
// something like this
public class DefaultableResourceBundle extends ResourceBundle {
private final ResourceBundle delegate;
private final UnaryOperator<String> defaultFunction;
private DefaultableResourceBundle(ResourceBundle delegate, UnaryOperator<String> defaultFunction) {
this.delegate = delegate;
this.defaultFunction= defaultFunction;
}
public static DefaultableResourceBundle of(ResourceBundle delegate, UnaryOperator<String> defaultFunction) {
return new DefaultableResourceBundle(delegate, defaultFunction);
}
@Override
public String getString(String key) {
// try to get it from the delegate, else apply
// defaultFunction on the key and return the result
}
// override getObject(), getStringArray() in a similar way
// override the abstract getKeys() to perform a simple delegation
}
Pro: You don’t have to maintain a list of test properties, nor add another dependency to your tested classes
Con: You’ll have to write a bit of code
What do you think?
6
I guess your DefaultableResourceBundle idea is a step into the right direction, though I guess currently is a little bit overengineered and may be implemented in a simpler manner. Moreover, I think you are mixing up the issue of not extending the constructor parameters with the issue of keeping your tests stable, these are two different things and should be approached separately.
Normally, I would say all you need for a stable test is one stable ResourceBundle instance, independent from any local application settings, and I guess your application has one or more default resource bundle files (or lists) which you can use and reuse in tests. Hence I am not convinced there is an urgent need for mocking this object. Of course, when you think there is no such default file available which is stable enough, you may derive a ResourceBundleMock from the abstract class ResourceBundle and provide methods which just return their input as output.
Then there is this second issue: you want to avoid the extra constructor parameter in your UI elements
GreetingPanel(ResourceBundle bundle)
which can indeed become somewhat annoying when you have several of such classes and objects to initialize.
Your idea to solve this is
ResourceBundle.getBundle("application");
directly inside GreetingPanel to get the bundle, which is nothing but the well-known Service Locator pattern. If I got this right, your code relies on this method returning null when run inside a test, and provide an instance of a class which can either behave as a ResourceBundle or as a mock for the former, depending on how it is initialized. For my taste, there is too much “overly clever” code necessary in each UI element with this solution (and a class where instances sometimes behave as a mock, sometimes as real resource bundle – seriously?).
My alternative suggestion would be to implement a very simple service locator, like a class MyResourceBundleProvider with a public method getBundle, which encapsulates the determination of the right resource bundle, something along the lines of
public class MyResourceBundleProvider
{
public static ResourceBundle getBundle()
{
// when in testing context, return a stable default bundle,
// or a ResourceBundleMock instance
//
// when in application context, return ResourceBundle.getBundle("application");
// ...
}
}
Now, the constructor of the GreetingPanel will look like this
public GreetingPanel() {
this.bundle = MyResourceBundleProvider.getBundle();
add(new JLabel(bundle.getString("greeting)));
}
which is IMHO simpler to understand and to maintain.
6
First, it is a good idea if most of your code doesn’t need to access any bundles at all, but just calls a method that returns a suitable string for some purpose. Why is this a good idea? Well, because first your boss told you “this doesn’t need localising, don’t use any resource bundles”, and six months later the exact same boss tells you “we need this localised into French, why don’t you have resource bundles”, and then it turns out some messages come from a server, and this and that, and all the time your code stays unchanged.
So you have one class responsible for everything. You inject whatever resource bundle you want into that class. So your same testing code can be adapted to check any localised resources.
I wouldn’t use a default bundle. Several methods: 1. You use an English bundle. 2. You use a bundle created by the developers, assuming they create a rough version, while someone else polishes it up to become the English version shown to customers. 3 Like Microsoft does, you create a language that is English with áççẽñťš everywhere, which shows quickly that everything is localised and nothing was forgotten.
2