What helps the programmer decide if a class is added to the ‘test’ folder hierarchy, as opposed to the ‘main’ folder?
If the project is purely aimed at automating, and primarily for testing i.e. there is no production application code, then:
Use ‘main’ for abstractions.
Use ‘test’ for adhoc utility @Test methods, unit tests and @Test methods that
would be run automatically e.g. during CI.
The above are guidelines, rather than absolute rules as different projects will make different decisions. But these are the guidelines I default to.
The code in ‘main’ is the library code used in @Test methods, but could also be
Looking at the code in ‘test’, you will see that most of it fits into this description. There are a few classes that don’t:
TracksResponseProcessor given a response will extract an id from a header.
This could validly be moved to ‘main’.
Wait in the synchronisation package could also be moved to the ‘main’
folder.
The above could justifiably be moved to the ‘main’ since they might be of use to other projects.
They represent a form of Technical Debt, simply because of the way the code has been written.
TestEnvDefaults
TestEnvDefaults is a configuration class to make it easy to create a TestEnv object
that represents the test environment. This is only used for the ‘test’ methods so I added it to the ‘test’ folder. Any other code that wants to use TestEnv can instantiate
a TestEnv of its own, and this is in the ‘main’ folder.
You saw snippets of TestEnvDefaults when we were looking at the test data
creation utility test.
You can find it in the source code:
src\test\java
package api.version_2_3_0.environmentconfig
It is a simple class used as a central place to configure the test environment location.
public class TestEnvDefaults {
public static final String theURL = "http://192.168.126.129"; public static final String adminUserName="user";
public static final String adminUserPassword="bitnami"; public static final String proxyUrl="localhost";
public static final int proxyPort=8000;
public static URL getURL() {
return URLifier.getURLfromString(theURL); }
public static String getAdminUserName() { return adminUserName;
public static String getAdminUserPassword() { return adminUserPassword;
}
public static String getProxyUrl() { return proxyUrl;
}
public static int getProxyPort() { return proxyPort;
}
public static TestEnv getTestEnv(){
TestEnv env = new TestEnv(theURL, adminUserName, adminUserPassword); env.configureProxy(proxyUrl, proxyPort);
env.setUseProxy(false); return env;
} }
The above class works well for the code given its current use case scenarios. Currently:
The code is used to support exercises and workshops. The tests are run from the IDE.
The environments are not stable, they are VMs run on individual machines and change frequently.
Tests are run for the purpose of learning how to automate a REST API rather than validate the function of the API so forcing people to amend the code helps them learn the code.
If the tests were run from CI on a regular basis then the above would not be good enough.
We might have defaults in a class to support local execution, but we would want the ability to override them during a CI process to point the tests at a specific
environment.
This would likely be done by having the static fields:
Not be final - so they can be changed by the code.
Not be public - so they are only changed by code in the class.
Use lazy instantiation,
when they are accessed then we would check if they were set to null, and
if so we would check for environment variables or system properties which can override hard coded defaults.
if no environment or system properties exist then set the values to hard coded defaults - coded as constants in the class.
In some production environments, the use of hard coded defaults would be viewed as dangerous because they might slip into production. As a result, we might choose not to have the TestEnvDefaults as a static class and instead force it to be instantiated.
We might also have the values configured externally to the code using: environment variables,
system properties, property file, etc.
Currently this code works well as an example, but this may not be a pattern that you want to use in your production test code.
Synchronisation
Synchronisation is an incredibly important concept for robust automated execution. Synchronisation means that we wait for the application to be in a particular state before we interact with it i.e. we synchronise with it to make sure it is ready.
If we get ‘out of sync’ with the application and try to exercise functionality before the application is ready to receive input then we can receive errors and the automated execution can fail.
Very often it can be hard to identify the reason for failures, and people often say that they have ‘random’ test failures or ‘flaky’ tests.
The root cause of much ‘flakiness’ in automated execution can often relate to ineffective synchronisation.
REST APIs have an inbuilt and very effective synchronisation mechanism since the synchronisation is inherent in the message passing process.
We send a message to the API.
Sometimes we have to have extra synchronisation for polling:
The API might be supporting a polling mechanism where we initiate a long running task with an API call and then poll to check for completion.
We might build synchronisation code that offers us a ‘wait’ by polling the API until the results are ready.
We may have to add additional synchronisation layers for particular application functionality or processing.
Synchronisation with
WaitThe Wait class is in: src\test\java
package api.version_2_3_0.synchronisation
This wait class is a ‘time based wait’. i.e. wait for 2 seconds
Very often people have an immediate reaction to a ‘time based wait’.