Running Groovy Tests in Docker: JAR Packaging vs Reflection Execution

After a data‑center migration caused high latency between the office network and the test environment, only a single Docker container remained for running tests, making the usual Groovy SDK approach infeasible.

Approach 1: Package the test class into a JAR and invoke its main method

A test class with a static main method is written, compiled, and packaged using Maven. The resulting JAR can be executed with a command such as:

java -cp okay_test-1.0-SNAPSHOT.jar com.okayqa.composer.performance.teach1_1.ActivityUnread 1 1 start

The article provides the full source of the test class, the Maven package command, and a sample console output that shows successful execution, including request logs, JSON responses, and performance metrics.

Approach 2: Use reflection to invoke arbitrary methods

A utility class ExecuteSource is introduced. It offers methods to:

Execute all non‑main methods in a given package.

Execute a specific method by fully‑qualified name, handling parameter types and values.

Retrieve all method names or class names in a package.

The implementation relies on Java reflection, logs warnings for illegal access or invocation errors, and includes helper functions for parameter conversion (e.g., Integer, JSON).

A demo class shows how to call ExecuteSource.executeMethod with a string array containing the target method path and paired type/value strings. The demo also demonstrates a common mismatch error where the method expects an int but an java.lang.Integer is supplied; the error is logged but does not prevent the subsequent successful call.

The article briefly mentions the Arthas tool, which can perform hot updates via the redefine command, but notes that it is more complex and less suitable for the presented problem.