Currently I am in process of writing large batches of Unit-Tests in the Project I am working on. Additionally we recently Introduced GUI-Testing. This project is a relatively simple webapp, on basis of Java EE 6.

Now my colleage did write quite some GuiTests, and I did write quite some Unit-Tests.

For both tests we need data to run them. Now we both took different approaches on how we "store" the data we use.

Solution 1:

public class UnitTestData {
     public static final String DATA_PIECE = "some data";
     public static final String MORE_DATA = "and more data";
     //... and so on

Solution 2:

public class GuiTestData {
    public String getDataPiece() {
        return "some data";

    public String getMoreData() {
        return "and more data";
    //... and so on.

My question now is: Which of these approaches is the objectively better one?


There are two arguments for using accessor methods instead of public variables:

  • Access Control: A method allows us to publish only a getter method, or to add value-based (in contrast to type-based) constraints on a setter. With public final identifiers, this point is irrelevant, as that value can't be changed, and invariants therefore can't be broken by client code.

  • Uniform Access: The method of accessing data in an object should not leak information on whether this data is stored or computed on the fly. In languages without “properties” – such as Java – this means that any data should be accessed via methods, and that no variable should ever be public. But why does the Uniform Access Principle exist in the first place? It's meant to reserve leeway for reimplementing the internals of an object without changing the public interface, so that client code using that object will not break.

    But in your situation there is no client code that uses a public API, you are just storing data for tests. Because there is no API to maintain, the justification for the UAP falls away (although following it does still get you all the advantages).

So there are no compelling arguments for using either solution. It's a pretty level field, and you can choose freely.

Note that using methods is absolutely required when each access needs to return a new instance. This is irrelevant for immutable objects such as strings. Otherwise, you should consider accessing all test data through methods for consistency's sake.

My personal opinion would be to choose the simplest thing possible, which would be using public final variables. However, please use member variables and not static ones, so that your tests can pass test data around as a first class object. (I know you can access static data via instances, but I consider that to be an anti-pattern).

If there are people on your team who are not familiar with Java, it might be better to store the test data in a configuration file (I recommend the YAML format). Instead of writing your own class, you would then be using the configuration file parser to access the data.


In my opinion solution depends how complex your testing environment is.

Solution no1 looks simpler and you are able to use import static to simplify it even more this way you follow kiss principle Also solution no1 performs better as you do not need to create another stack call on thread that takes place in solution no 2.

However solution no2 seems to work better in more advanced testing scenarios when you have to test sets of data. In this case you would have to externalize an interface e.g. GuiDataSource which GuiTestData would have to implement in order to create more implementations similar to GuiTestData and inject them on runtime during the testing phase. You can easily also mock up everything in solution no2 and use reflections to do a lot of magic.

  • I don't really understand the point you make about "GuiDataSource". Why would I create an interface for a Test-Data Provider? And why should GuiTestData implement it?
    – Vogel612
    Sep 4 '14 at 14:58
  • In order to write an GUI test only once and then execute it against different (test-) data sources (=providers). Sep 4 '14 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.