Setup Unit Test Environment

The goal of this document is to provide comprehensive documentation to understand how to set up the environment for testing.

1.1 Before you start:

Before you start make sure you are using Maven for building Java applications and artifacts and that your application is managed by google AppEngine.

1.2 Setting up:

1.2.0 Library in Eclipse classpath

The JUnit 5 jar is required to be added in Eclipse because Eclipse does not include JUnit 5 by default. Even if you have the JUnit Jupiter dependencies added in your Maven pom.xml, Eclipse needs to have the JUnit 5 library in its classpath in order to run and execute JUnit 5 tests within the Eclipse IDE.

When you add the JUnit 5 dependencies in your Maven pom.xml, it allows you to compile and build your project using Maven. However, it does not automatically configure the Eclipse IDE to recognize and execute JUnit 5 tests. That's why you need to manually add the JUnit 5 jar to Eclipse's build path.

To configure the build path navigate to your respective Project->Build Configure…->Library->Add Library->Junit 5.

By adding the JUnit 5 jar to Eclipse, you ensure that Eclipse recognizes and supports JUnit 5 tests, allowing you to run and debug them directly within the IDE.

1.2.1 Maven Dependencies

You have to add maven dependencies carefully as many version conflicts will arise. I am suggesting the stable one here.

<!-- The appengine-api-stubs dependency is required when writing unit tests for Google App Engine applications. It provides stub implementations of the Google App Engine APIs, allowing you to simulate the behavior of the App Engine environment during testing.
		Integration with App Engine services: appengine-api-stubs provides stubs that closely mimic the behavior of Google App Engine services. This allows you to write tests that interact with the App Engine services in a more realistic way, including features specific to the platform, such as Datastore, Memcache, Task Queue, and more. -->
		<dependency>
			<groupId>com.google.appengine</groupId>
			<artifactId>appengine-api-stubs</artifactId>
			<version>1.9.80</version>
			<scope>test</scope>
		</dependency>

<!-- To acquire in-memory database for testing DAO layer, H2 database can be used at ease. -->
        <dependency>
			<groupId>com.h2database</groupId>
			<artifactId>h2</artifactId>
			<version>1.4.200</version>
		</dependency>

These dependencies must be in management to avoid conflict with another jars in pom file. Listed below are points why to use Juint 5 dependency.

Improved Programming Model: JUnit 5 provides a more flexible and modern programming model for writing tests. It introduces annotations and extensions that allow you to organize and structure your tests in a more readable and maintainable way.

Enhanced Assertions: JUnit 5 offers an enhanced set of assertion methods, making it easier to write expressive and meaningful test assertions. Assertions like assertEquals, assertTrue, assertFalse, etc., are available to validate the expected behavior of your code.

Parameterized Tests: JUnit 5 introduces parameterized tests, which allow you to run the same test logic with different sets of input data. This simplifies writing and maintaining tests for scenarios where you want to test multiple input values or combinations.

Nested Tests: JUnit 5 allows you to create nested test classes, which improves test organization and readability. You can group related tests together within a nested class structure, making it easier to understand the relationships between different tests.

Extensions and Customization: JUnit 5 provides a powerful extension model that allows you to extend and customize the testing framework. You can use extensions to add additional behavior or features to your tests, such as test lifecycle callbacks, parameter resolvers, custom annotations, etc.

Improved IDE Integration: JUnit 5 offers improved IDE integration with modern Java IDEs. IDEs like IntelliJ IDEA, Eclipse, and NetBeans provide native support for running and debugging JUnit 5 tests, making it convenient to execute and analyze test results within the development environment.

By including the JUnit 5 dependency in your project, you can take advantage of these features and benefits to write effective, maintainable, and readable unit tests for your Java code.
    
		<dependencyManagement>
		 <dependencies>
			<!-- JUnit Jupiter API -->
			<dependency>
				<groupId>org.junit.jupiter</groupId>
				<artifactId>junit-jupiter-api</artifactId>
				<version>5.8.1</version>
				<scope>test</scope>
			</dependency>

			<!-- JUnit Jupiter Engine -->
			<dependency>
				<groupId>org.junit.jupiter</groupId>
				<artifactId>junit-jupiter-engine</artifactId>
				<version>5.8.1</version>
				<scope>test</scope>
			</dependency>

			<!-- JUnit Jupiter Params -->
			<dependency>
				<groupId>org.junit.jupiter</groupId>
				<artifactId>junit-jupiter-params</artifactId>
				<version>5.8.1</version>
				<scope>test</scope>
			</dependency>

			<!-- JUnit Jupiter Vintage -->
			<dependency>
				<groupId>org.junit.vintage</groupId>
				<artifactId>junit-vintage-engine</artifactId>
				<version>5.8.1</version>
				<scope>test</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

The Mockito dependency used for mocking classes and interfaces.

		<dependency>
			<groupId>org.mockito</groupId>
			<artifactId>mockito-all</artifactId>
			<version>1.10.19</version>
			<scope>test</scope>
		</dependency>

1.2.2 Maven Plugins

The Surefire Plugin is used during the test phase of the build lifecycle to execute the unit tests of an application. 
It generates reports in two different file formats: Plain text files ( *. txt ).
Surefire is used to automate the execution of tests during the Maven build process and generate test reports


   <properties>
 	    <app.testing.jvm.args></app.testing.jvm.args> //When running tests using Maven, the specified JVM arguments will be passed to the JVM executing the tests, allowing you to customize the test environment as needed.
		<maven.surefire.version>2.22.0</maven.surefire.version>
	</properties>

	       <plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-surefire-plugin</artifactId>
				<version>${maven.surefire.version}</version>
				<configuration>
					<argLine>@{argLine} ${app.testing.jvm.args} -Xmx1536m</argLine>
				</configuration>
			</plugin>

	This plugin is used for analysis of test coverage report and inclusion/exclusion of
	packages from test coverage. In eclipse we have similar code coverage tool i.e. EclEmma that can be used to cacluate test coverage report 
	
             <plugin>
				<groupId>org.jacoco</groupId>
				<artifactId>jacoco-maven-plugin</artifactId>
				<version>0.7.9</version>
				<configuration>
					<excludes>
						<exclude>**/*auth/*</exclude>
						<exclude>**/*model/*</exclude>
					</excludes>
				</configuration>
				<executions>
					<!-- prepare agent for measuring integration tests -->
					<execution>
						<id>jacoco-initialize</id>
						<goals>
							<goal>prepare-agent</goal>
						</goals>
					</execution>
					<execution>
						<id>jacoco-site</id>
						<phase>package</phase>
						<goals>
							<goal>report</goal>
						</goals>
					</execution>
					<execution>
						<id>coverage-check</id>
						<goals>
							<goal>check</goal>
						</goals>
						<configuration>
							<dataFile>target/jacoco.exec</dataFile>

							<rules>
								<rule>
									<element>PACKAGE</element>

									<limits>
										<limit>
											<counter>INSTRUCTION</counter>
											<value>COVEREDRATIO</value>
											<minimum>0.70</minimum>
										</limit>
									</limits>
								</rule>
							</rules>
						</configuration>
					</execution>
				</executions>
			</plugin>

1.3 Setup for a writing test case:

Select the respective class which you want to test. Right-click on the class, select new, and choose others from the menu bar and then select the JUnit test case.

Then move to the next and choose a package name and the methods you want to be served when the test class is created.

Project Packaging Structure: It is recommended to follow the below packing structure.

src

src/main/java – This folder contains Java source code packages and classes
src/main/resources – This folder contains non-java resources, such as property files and application configuration.

Test

src/test/java – This folder contains the test source code packages and classes
src/test/resources – This folder contains non-Java resources, such as property files and application configuration.

Test cases source folder should not be included in the main application source folder, earlier it seems like standard but will create lots of bugs when you deploy your application to an external server.

Now select the “Next” option and choose the methods which you basically want to test.

JUnit will make those functions ready for you. Now add your implementation to that function or you can manually create other functions if required.

1.4 Setup mocks/AppEngine stubs

Mocks and App Engine stubs are used in the context of testing to simulate or emulate certain behavior or dependencies that your code relies on. They serve different purposes:

Mocks: Mocks are objects that mimic the behavior of real objects but provide controlled and predictable responses. They are commonly used in unit testing to isolate the code under test and verify its interactions with external dependencies. With mocking frameworks like Mockito, you can create mock objects that simulate the behavior of dependencies and define their expected responses. This allows you to focus on testing the specific behavior of your code without relying on the actual implementation of the dependencies.
App Engine Stubs: App Engine stubs are specific to the Google App Engine platform and provide simulated versions of the App Engine services. These stubs are used in unit testing to replicate the behavior of App Engine services, such as Datastore, Memcache, or Task Queue, Memcache, Redis using Jedis and other related functionalities i.e. HttpServletRequest, HttpSesssion, etc. without actually making requests to the live services. By using App Engine stubs, you can write tests that interact with these services in a controlled and isolated environment. This helps in testing your App Engine application's logic and integration with App Engine services without the need for live service calls or deploying to the production environment.

Let’s learn how to set up mocks that will be used for testing our real-time AppEngine applications.

How to set up mocks for Java Servlet API?

How to set up mocks for Memcache?

How to set up mocks for Redis?

How to set up mocks for the Task queue?

1.5 Setup in-memory database for testing data access layer (DAO)

It is recommended to use an in-memory database to avoid direct interaction with the production database. Also, there is no issue of dummy data being inserted in the prod environment.

Using an in-memory database for testing the DAO (Data Access Object) layer offers several advantages:

Isolation: An in-memory database allows you to isolate the tests from the production database. Each test can run independently and have its own dedicated database instance. This ensures that the tests do not interfere with each other and avoids any unexpected side effects.
Speed: In-memory databases are usually faster than traditional disk-based databases because they store data in memory rather than on disk. This can significantly speed up the execution of tests, allowing you to run a larger number of tests in a shorter amount of time.
Simplicity: In-memory databases are lightweight and easy to set up. They don't require complex database configurations or external dependencies. You can create the necessary database schema, populate it with test data, and run the tests without the need for an actual running database server.
Deterministic Behavior: In-memory databases provide a consistent and predictable environment for testing. Since the data is stored in memory, there are no external factors such as network latency or disk I/O that can affect the test results. This helps in producing reliable and reproducible tests.
Test Coverage: With an in-memory database, you can test various scenarios and edge cases more easily. You can simulate different data states, perform CRUD operations, and validate the behavior of your DAO layer without worrying about the impact on the production database.
Portability: In-memory databases are typically self-contained and portable. They can be easily configured and deployed as part of your test environment, making it convenient to run tests on different development machines or in a continuous integration (CI) environment.

By using an in-memory database for testing the DAO layer, you can ensure that your database operations are properly implemented and function correctly without the overhead and complexity of a real database server. It promotes efficient and reliable testing of your data access code and helps identify issues early in the development process.

Let's learn how to set up an in-memory database to run the tests for the Dao layer.

How to set up an in-memory database | MySql?

Software Development