Running Tests

Relevant source files

The following files were used as context for generating this wiki page:

• test/run.sh
• complete/pom.xml
• complete/src/test/java/com/example/restservice/GreetingControllerTests.java
• initial/src/test/java/com/example/restservice/RestServiceApplicationTests.java
• README.adoc
• initial/pom.xml
• complete/gradlew.bat

This document outlines the testing strategy for the gs-rest-service project. The project employs a combination of automated build verification scripts, Spring Boot integration tests, and manual verification steps. Testing is configured for both Maven and Gradle build systems and covers both the initial and complete states of the project.

The primary goal of the tests is to ensure the REST service correctly handles GET requests to the /greeting endpoint, provides default values, and processes query parameters as expected. The testing framework is built upon Spring Boot's testing support, which integrates seamlessly with JUnit 5.

Test Infrastructure and Configuration

The project's testing capabilities are primarily configured through the Maven pom.xml file, which includes the necessary dependencies for the Spring Boot test framework.

Test Dependencies

The core dependency for testing is spring-boot-starter-test. This starter package bundles key testing libraries, including Spring Test, JUnit 5, and Mockito. It is defined with a test scope, meaning it is only available during the test phase of the build lifecycle and is not included in the final packaged application.

Sources: complete/pom.xml:28-32, initial/pom.xml:28-32

Group ID	Artifact ID	Scope	Description
org.springframework.boot	spring-boot-starter-test	test	Provides core Spring Boot testing utilities, including support for JUnit, Hamcrest, and Mockito.

Sources: complete/pom.xml:28-32

Automated Test Execution

The project includes a shell script, run.sh, designed to automate the build and test process for both the initial and complete project versions, using both Maven and Gradle. This script serves as a continuous integration check to validate the integrity of both project states.

Sources: test/run.sh

run.sh Execution Flow

The script executes a series of build and cleanup commands in a specific order. It first validates the initial project and then moves to the complete project. Any failure in the sequence will cause the script to exit with a non-zero status code.

The following diagram illustrates the workflow of the run.sh script.

run.sh Command Breakdown

Command	Project	Description
./mvnw clean compile	initial	Cleans the target directory and compiles the source code using the Maven wrapper.
./gradlew compileJava	initial	Compiles the Java source code using the Gradle wrapper.
./mvnw clean package	complete	Cleans the target directory and packages the application, which includes running the tests.
./gradlew build	complete	Builds the project, which includes compiling, testing, and assembling the application into a JAR.

Sources: test/run.sh:4-22

Spring Boot Integration Tests

The complete version of the project contains integration tests for the GreetingController. These tests use MockMvc to simulate HTTP requests and verify the responses without needing to run a full web server.

Sources: complete/src/test/java/com/example/restservice/GreetingControllerTests.java

Test Class Setup

The GreetingControllerTests class is annotated with @SpringBootTest and @AutoConfigureMockMvc.

• @SpringBootTest: Loads the full Spring application context for an integration test.
• @AutoConfigureMockMvc: Configures a MockMvc instance, which is then autowired into the test class.

Sources: complete/src/test/java/com/example/restservice/GreetingControllerTests.java:29-30

Test Cases

Two primary test cases validate the functionality of the /greeting endpoint.

Test Method	Endpoint	Parameters	Expected Behavior
noParamGreetingShouldReturnDefaultMessage	/greeting	None	Returns HTTP 200 OK with the JSON content "Hello, World!".
paramGreetingShouldReturnTailoredMessage	/greeting	name=Spring Community	Returns HTTP 200 OK with the JSON content "Hello, Spring Community!".

Sources: complete/src/test/java/com/example/restservice/GreetingControllerTests.java:36-48

The following sequence diagram shows the flow for the paramGreetingShouldReturnTailoredMessage test.

This diagram illustrates how MockMvc simulates a web request that is processed by the DispatcherServlet and GreetingController, allowing assertions to be made on the resulting response.

Sources: complete/src/test/java/com/example/restservice/GreetingControllerTests.java:44-47

Initial Project Test

The initial project contains a basic sanity check test that ensures the Spring application context can be loaded successfully. The contextLoads() test will pass if the application starts without any configuration errors.

@SpringBootTest
public class RestServiceApplicationTests {

	@Test
	public void contextLoads() {
	}

}

Sources: initial/src/test/java/com/example/restservice/RestServiceApplicationTests.java:6-13

Manual Testing

In addition to automated tests, the README.adoc file describes steps for manually testing the running service. This is useful for quick verification after deploying or running the application locally.

1. Test the default greeting:

   • Access http://localhost:8080/greeting
   • Expected JSON response: {"id":1,"content":"Hello, World!"}

2. Test the customized greeting:

   • Access http://localhost:8080/greeting?name=User
   • Expected JSON response: {"id":2,"content":"Hello, User!"}

This manual check confirms that the @RequestParam is working correctly and that the controller's state (the counter) is being updated across requests.

Sources: README.adoc:123-145