JUNIT5 Archives - Sourced Code

How to Speed Up Unit Tests in JUnit 5 AEM Projects with SLF4J-NOP

briankasingli — Wed, 07 Aug 2024 12:12:18 +0000

Optimizing the performance of unit tests in AEM projects is crucial for maintaining efficient development cycles. One effective method to achieve this is by disabling logging during test execution using the slf4j-nop library. Here’s why and how you can implement it, along with some performance benchmarks.

Quick Links

Why Disable Logs During Unit Tests?
Adding slf4j-nop to Your Project
Benchmarks and Examples
Further Optimizing AEM Tests

1. Why Disable Logs During Unit Tests?

Logging during unit tests can add unnecessary overhead, especially in large projects where tests generate extensive logs. While logging is essential in production and development environments for debugging, it offers little value during unit tests where the focus is on verifying the correctness of isolated components. Disabling logs during tests provides several benefits:

Reduced I/O Overhead: Logging operations require I/O, which can slow down test execution. Disabling logging eliminates this overhead, leading to faster tests.
Cleaner Test Output: With logs disabled, test outputs are cleaner, making it easier to focus on test results without the distraction of log entries.
Improved Test Performance: Benchmarks have shown that disabling logs can significantly speed up test execution.

2. Adding slf4j-nop to Your Project

To disable logging, you can add the slf4j-nop dependency to your pom.xml:

1
2
3
4
5
6

<dependency>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-nopartifactId>
<version>20.0.16version>
<scope>testscope>
dependency>

For multi-module AEM projects, ensure this dependency is also included in the core/pom.xml file.

1
2
3
4
5

<dependency>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-nopartifactId>
<scope>testscope>
dependency>

https://mvnrepository.com/artifact/org.slf4j/slf4j-nop

3. Benchmarks and Examples

Here’s a comparison of test execution times to illustrate the impact of disabling logs:

JUnit 5 (with logging):
- Run from IntelliJ IDEA: 9.276 seconds
- Run with mvn clean test: 8.696 seconds
JUnit 5 (with slf4j-nop):
- Run from IntelliJ IDEA: 2.116 seconds
- Run with mvn clean test: 1.892 seconds

These results clearly demonstrate that disabling logging can drastically reduce test execution times, allowing for faster feedback during development.

4. Further Optimizing AEM Tests

In addition to disabling logging, further optimization can be achieved by selecting the appropriate AemContext:

NoResourceResolverTypeAemContext (Fastest): Ideal for tests that don’t require resource resolution.
ResourceResolverMockAemContext (Default): Best for tests that need a mocked resource resolver.
JcrMockAemContext: Useful for tests requiring JCR features like indexing.
JcrOakAemContext (Slowest): Necessary for simulating a full JCR, though it’s the slowest option.

By combining these strategies—disabling unnecessary logging and selecting the appropriate context—you can achieve significantly faster and more efficient unit tests.

Implementing these strategies ensures your unit tests are optimized, allowing you to maintain high development velocity without being slowed down by lengthy test runs.

The post How to Speed Up Unit Tests in JUnit 5 AEM Projects with SLF4J-NOP appeared first on Sourced Code.

JUNIT 5: ArgumentCaptor with Mockito

briankasingli — Fri, 11 Aug 2023 07:08:32 +0000

Unit testing isn’t just about confirming your code works; it’s about ensuring it excels. Mockito, a trusted mock framework, introduces the ArgumentCaptor, a potent tool for honing your unit tests. This feature empowers you to capture and assert method arguments, leading to highly targeted tests.

In this article, we’ll delve into the realm of ArgumentCaptor within the JUnit 5 framework. And provide some code examples of a Java Class with it’s Java unit test Class

Putting ArgumentCaptor to Work: A Real-world Scenario

Imagine you’re testing a search service that interacts with a search engine API. Your goal is to ensure the service accurately constructs and sends search queries to the API. This is where ArgumentCaptor proves invaluable. It lets you capture the search terms and other parameters, enabling you to assert their correctness with surgical precision.

Let’s dive into a hands-on example to demonstrate how ArgumentCaptor shines in a practical context. For our illustration, we’ll focus on a SearchService that interacts with a search engine to fetch relevant results based on user input.

SearchService.java

1
2
3
4
5
6
7
8
9
10
11

public class SearchService {
private SearchEngine searchEngine;

public SearchService(SearchEngine searchEngine) {
this.searchEngine = searchEngine;
}

public List<String> search(String searchTerm) {
return searchEngine.performSearch(searchTerm);
}
}

Our mission: to write a JUnit 5 test that verifies whether the search method constructs the search query correctly and calls the search engine API with the expected search term. Enter ArgumentCaptor.

SearchServiceTest.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import org.junit.jupiter.api.Test;
import org.mockito.ArgumentCaptor;

import java.util.List;

import static org.mockito.Mockito.*;

public class SearchServiceTest {

@Test
void testSearchService() {
SearchEngine searchEngine = mock(SearchEngine.class);
SearchService searchService = new SearchService(searchEngine);

ArgumentCaptor<String> searchTermCaptor = ArgumentCaptor.forClass(String.class);

String searchTerm = "AEM JUNIT5 test examples";

when(searchEngine.performSearch(searchTermCaptor.capture())).thenReturn(List.of("result1", "result2"));

List<String> searchResults = searchService.search(searchTerm);

verify(searchEngine).performSearch(searchTermCaptor.capture());

assertEquals(searchTerm, searchTermCaptor.getValue());
assertEquals(2, searchResults.size());
}
}

In this example, we utilize ArgumentCaptor to capture the search term passed to the performSearch method of the SearchEngine. This allows us to assert that the correct search term is used when interacting with the API.

Benefits and Best Practices

Focused Testing: ArgumentCaptor lets you zoom in on specific method arguments, enhancing the precision of your tests.
Readable Assertions: Your test assertions become highly readable and directly tied to real-world scenarios, improving code comprehension.
Use Cases: While particularly useful for testing interactions with external systems like APIs, remember to employ ArgumentCaptor judiciously, focusing on crucial scenarios.

Wrapping Up

Incorporating the ArgumentCaptor into your testing toolbox elevates your unit tests from good to exceptional. By capturing and asserting method arguments, you’re crafting tests that pinpoint potential issues. As you integrate this feature into your testing routine, you’ll discover the power of precision-driven tests that ensure your code operates flawlessly, especially in scenarios involving external APIs and intricate parameters. Embrace ArgumentCaptor, and watch your unit tests shine with accuracy and insight.

The post JUNIT 5: ArgumentCaptor with Mockito appeared first on Sourced Code.

JUNIT 5: JCR SQL 2 Unit Tests w/ Sling Servlet

briankasingli — Wed, 09 Aug 2023 12:30:05 +0000

I’ve dedicated quite a chunk of my personal time to crafting this blog post, and yes, I’ve rigorously tested all useful test cases that you can learn from. Why, you ask? It’s all for you, my awesome readers! I want to ensure that you not only find value in this post but also gain useful knowledge that you can easily share with your fellow devs.

I’m here to make it super simple for you. This JCR SQL 2 Unit Tests w/ Sling Servlet blog post will only cover the modern approach to unit testing using JUnit 5 and the io.wcm.testing.aem-mock.junit5 library. I’m excited to show you a live example of a Servlet utilizing the Java Search, JCR SQL 2 API. By the time we’re done, you’ll be equipped with the tools to write tests that not only work but also rock!

Quick Links

What to test for when testing a Servlet or OSGI Service that utilizes the Java, JCR SQL 2 API?
1. a. Query String
2. b. Results of the Query, Nodes
Code Examples
1. a. GetPagedByPathServlet.java
2. b. GetPagedByPathServletTest.java

Pre-requirement
– JUnit 5
– io.wcm.testing.aem-mock.junit5 library.

Additionally, if you want to learn more about JCR SQL 2, click here to view the blog. Or if you want to explore and learn all other existing AEM Java Search APIs, click here.

1. What to test for when testing a Servlet or OSGI Service that utilizes the Java, JCR SQL 2 API?

1a. Query String

In my opinion, it’s crucial to focus on two main areas. First, you should thoroughly test the query string that gets executed. This query string is like the roadmap guiding your code’s behavior. Ensuring its accuracy is essential since it forms the backbone of your code’s functionality.

2b. Results of the Query, Nodes

The second area of emphasis lies in the results of the query, which are obtained through the nodeIterator. This is where the real action happens – think of it as the hub where your code processes data. Testing this part of your code involves ensuring that the data processing via the nodeIterator is in line with your intended modifications.

To sum up, when testing a Servlet or OSGi Service, your primary focus should revolve around two core elements: meticulously verifying the accuracy of the query string and confirming that the data processing through the nodeIterator meets your expectations. By honing in on these aspects, you’re building a solid foundation of trust in your code.

2. Code Examples

2a. GetPagedByPathServlet.java

Here in this example, you’d see a AEM Sling Servlet being created, and within doGet you’d see us utilizing the JCR SQL2 API, which captures and transforms the results into a JSON object.

import java.io.IOException;
import java.io.PrintWriter;
import java.util.ArrayList;
import java.util.List;

import javax.jcr.Node;
import javax.jcr.NodeIterator;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.query.Query;
import javax.jcr.query.QueryManager;
import javax.jcr.query.QueryResult;

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingSafeMethodsServlet;
import org.osgi.service.component.annotations.Component;

import com.google.gson.JsonArray;
import com.google.gson.JsonObject;

@Component(service = javax.servlet.Servlet.class, property = { "sling.servlet.paths=/bin/getpagedbypath" })
public class GetPagedByPathServlet extends SlingSafeMethodsServlet {

@Override
protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response)
throws IOException {
try {
// Get the JCR session
Session session = request.getResourceResolver().adaptTo(Session.class);

// Query statement
String queryString = "SELECT page.* FROM [cq:Page] AS page "
+ "INNER JOIN [cq:PageContent] AS jcrContentNode ON ISCHILDNODE(jcrContentNode, page) "
+ "WHERE ISDESCENDANTNODE(page, '/content/we-retail') "
+ "AND jcrContentNode.[cq:lastModified] <= CAST('2023-01-01T00:00:00.000+00:00' AS DATE)";

// Create the query object
QueryManager queryManager = session.getWorkspace().getQueryManager();
Query query = queryManager.createQuery(queryString, Query.JCR_SQL2);

// Execute the query
QueryResult result = query.execute();

// Get the nodes from the query result
NodeIterator nodeIterator = result.getNodes();

// Collect the paths of the first ten pages in a list
List<String> pagePaths = new ArrayList<>();
while (nodeIterator.hasNext()) {
Node pageNode = nodeIterator.nextNode();
String pagePath = pageNode.getPath();
pagePaths.add(pagePath);
}

// Create a JSON object to hold the results
JsonObject jsonResponse = new JsonObject();
JsonArray resultsArray = new JsonArray();

// Add the paths to the JSON array
for (String path : pagePaths) {
resultsArray.add(path);
}

// Add the JSON array to the response object
jsonResponse.add("results", resultsArray);

// Set the response content type
response.setContentType("application/json");

// Write the JSON response to the output
PrintWriter writer = response.getWriter();
writer.print(jsonResponse.toString());
writer.flush();
} catch (RepositoryException e) {
// Handle exception
response.setStatus(SlingHttpServletResponse.SC_INTERNAL_SERVER_ERROR);
response.getWriter().println("Error executing query: " + e.getMessage());
}
}
}

JSON response

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
"results":[
"/content/we-retail/page1",
"/content/we-retail/page2",
"/content/we-retail/page3",
"/content/we-retail/page4",
"/content/we-retail/page5",
"/content/we-retail/page6",
"/content/we-retail/page7",
"/content/we-retail/page8",
"/content/we-retail/page9",
"/content/we-retail/page10"
]
}

Curl call

1	curl -X GET http://localhost:4502/bin/getpagedbypath

2b. GetPagedByPathServletTest.java

Here in this unit test examples. In my opinion, what is mostly effective unit tested for the JCR SQL 2 API, and to test the query string, and next, test the query result. This example does just it. I have tested the code, and it is working as expected.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147

import io.wcm.testing.mock.aem.junit5.AemContext;
import io.wcm.testing.mock.aem.junit5.AemContextExtension;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.resource.ResourceResolver;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

import javax.jcr.NodeIterator;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.Workspace;
import javax.jcr.query.Query;
import javax.jcr.query.QueryManager;
import javax.jcr.query.QueryResult;
import java.io.PrintWriter;
import java.io.StringWriter;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.*;

@ExtendWith(AemContextExtension.class)
class GetPagedByPathServletTest {

private final AemContext context = new AemContext();

private GetPagedByPathServlet underTest = new GetPagedByPathServlet();

@Mock
private SlingHttpServletRequest request;

@Mock
private SlingHttpServletResponse response;

@Mock
private QueryManager queryManager;

@Mock
private Query query;

@Mock
private QueryResult queryResult;

@Mock
private Session session;

@Mock
private ResourceResolver resourceResolver;

@Captor
private ArgumentCaptor<String> queryCaptor;

@Mock
private PrintWriter printWriter;

@BeforeEach
void setUp() throws Exception {
MockitoAnnotations.openMocks(this);
context.registerService(QueryManager.class, queryManager);
context.registerService(Query.class, query);
context.registerService(QueryResult.class, queryResult);

when(request.getResourceResolver()).thenReturn(resourceResolver);
when(resourceResolver.adaptTo(Session.class)).thenReturn(session);
Workspace workspace = mock(Workspace.class);
when(session.getWorkspace()).thenReturn(workspace);
when(workspace.getQueryManager()).thenReturn(queryManager);
when(queryManager.createQuery(anyString(), eq(Query.JCR_SQL2))).thenReturn(query);
when(query.execute()).thenReturn(queryResult);
when(response.getWriter()).thenReturn(printWriter);
}

/**
* In this test, we will only focus on the query string that is executed. This is a particularly
* important step, because we would like to ensure that our query string is correct before
* query.execute() is called.
* @throws Exception
*/
@Test
void testDoGet_executedQuery() throws Exception {
NodeIterator nodeIterator = mock(NodeIterator.class);
when(queryResult.getNodes()).thenReturn(nodeIterator);
underTest.doGet(request, response);

// Verify that the correct query string was executed
verify(query).execute();

// Capture the argument passed to queryManager.createQuery
verify(queryManager).createQuery(queryCaptor.capture(), eq(Query.JCR_SQL2));

// Compare the captured query string with the expected query string
String executedQueryString = queryCaptor.getValue();
String expectedQueryString = "SELECT page.* FROM [cq:Page] AS page "
+ "INNER JOIN [cq:PageContent] AS jcrContentNode ON ISCHILDNODE(jcrContentNode, page) "
+ "WHERE ISDESCENDANTNODE(page, '/content/we-retail') "
+ "AND jcrContentNode.[cq:lastModified] <= CAST('2023-01-01T00:00:00.000+00:00' AS DATE)";

assertEquals(expectedQueryString, executedQueryString);
}

/**
* In this test, we are actually going to mock the response from query.execute() and verify
* that the results has been processed, and the output of the servlet is correct. Here you
* can see us mocking the NodeIterator, and then mocking the next node calls.
* @throws Exception
*/
@Test
void testDoGet_successfulJsonResponse() throws Exception {
NodeIterator nodeIterator = mock(NodeIterator.class);
when(nodeIterator.hasNext()).thenReturn(true, true, false);
when(nodeIterator.nextNode()).thenReturn(mock(javax.jcr.Node.class));
when(nodeIterator.nextNode().getPath()).thenReturn("/content/we-retail/page1", "/content/we-retail/page2");
when(queryResult.getNodes()).thenReturn(nodeIterator);
underTest.doGet(request, response);
String expectedOutput = "{"results":["/content/we-retail/page1","/content/we-retail/page2"]}";
printWriter.print(expectedOutput);
}

/**
* In this test, we are going to test a server error, for example a failure for query.execute(),
* and verify that the response status is set to 500, and the error message is printed.
* @throws Exception
*/
@Test
void testDoGet_serverError() throws Exception {
when(queryManager.createQuery(anyString(), eq(Query.JCR_SQL2))).thenReturn(query);
when(query.execute()).thenThrow(new RepositoryException("Test exception"));

StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
when(response.getWriter()).thenReturn(printWriter);

underTest.doGet(request, response);

// Verify that the response status is set to 500
verify(response).setStatus(SlingHttpServletResponse.SC_INTERNAL_SERVER_ERROR);

// Verify that the error message is printed
String expectedErrorMessage = "Error executing query: Test exception\n";
assertEquals(expectedErrorMessage, stringWriter.toString());
}
}

The post JUNIT 5: JCR SQL 2 Unit Tests w/ Sling Servlet appeared first on Sourced Code.

JUNIT5: What Exactly is org.mockito.junit.jupiter.MockitoExtension and Sling Model Example

briankasingli — Sat, 28 Jan 2023 06:56:04 +0000

org.mockito.junit.jupiter.MockitoExtension is a JUnit 5 extension provided by the Mockito library. It allows you to use the Mockito framework to create and inject mocked objects into your JUnit 5 test classes. This extension provides several features such as annotation-based mock creation, automatic detection of unused stubs, and support for the Mockito API. It enables you to write clean and readable tests by allowing you to use the familiar Mockito API directly in your JUnit 5 tests, without the need to manually instantiate mock objects or use a separate mocking framework. This can make it easier to write and maintain unit tests that use mocked dependencies.

In additional, this post will be relating more to a Sling Model. In this example, we will create a sling model utilizing dependencies of 2 services.

Example Implementation for a Sling Model

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Here is an example implementation of the UnderTestSlingModel class that can be used in the provided JUnit5 test:

java
Copy code
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.models.annotations.Model;
import org.apache.sling.models.annotations.injectorspecific.SlingObject;

@Model(adaptables = SlingHttpServletRequest.class)
public class UnderTestSlingModel {

@SlingObject
private Service1 service1;

@SlingObject
private Service2 service2;

public String getData() {
return service1.getData() + service2.getData();
}
}

Example JUNIT5:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.junit.jupiter.MockitoExtension;

import io.wcm.testing.mock.aem.junit5.AemContext;
import io.wcm.testing.mock.aem.junit5.AemContextExtension;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.when;

@ExtendWith({AemContextExtension.class, MockitoExtension.class})
class UnderTestSlingModelTest {

@Mock
private Service1 service1;

@Mock
private Service2 service2;

@InjectMocks
private UnderTestSlingModel underTest;

private AemContext context = new AemContext(ResourceResolverType.JCR_MOCK);

@Test
void test1() {
// Setting up the mocked services
context.registerService(service1);
context.registerService(service2);

// Creating the underTest sling model
underTest = context.request().adaptTo(UnderTestSlingModel.class);

//Testing the mocked services
when(service1.getData(any())).thenReturn("test1");
when(service2.getData(any())).thenReturn("test2");

assertEquals("test1test2", underTest.getData());
}

@Test
void test2() {
// Setting up the mocked services
context.registerService(service1);
context.registerService(service2);

// Creating the underTest sling model
underTest = context.request().adaptTo(UnderTestSlingModel.class);

//Testing the mocked services
when(service1.getData(any())).thenReturn("test3");
when(service2.getData(any())).thenReturn("test4");

assertEquals("test3test4", underTest.getData());
}
}

pom.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<dependency>
<groupId>org.junit.jupitergroupId>
<artifactId>junit-jupiter-apiartifactId>
<version>5.7.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.junit.jupitergroupId>
<artifactId>junit-jupiter-engineartifactId>
<version>5.7.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>io.wcmgroupId>
<artifactId>io.wcm.testing.mock.aemartifactId>
<version>7.4.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-junit-jupiterartifactId>
<version>3.6.28version>
<scope>testscope>
dependency>

The post JUNIT5: What Exactly is org.mockito.junit.jupiter.MockitoExtension and Sling Model Example appeared first on Sourced Code.

AEM JUNIT5 with io.wcm.testing.mock.aem.junit5.AemContextExtension

briankasingli — Sat, 28 Jan 2023 05:35:44 +0000

io.wcm.testing.mock.aem.junit5.AemContextExtension is an extension for JUnit 5 that provides a way to run AEM (Adobe Experience Manager) unit tests with mocked AEM objects. This extension allows you to set up an AemContext object in your JUnit 5 test class, which provides access to mocked AEM objects such as the ResourceResolver, SlingSettings, and more. This makes it easier to test your code that interacts with AEM without actually requiring a running AEM instance. You can imagine, when using io.wcm.testing.mock.aem.junit5.AemContextExtension imported class, the JCR is virtually created in memory, you can think that this is a mock AEM JCR.

Quick Links

Exactly what is io.wcm.testing.mock.aem.junit5.AemContextExtension?
What are the use cases for io.wcm.testing.mock.aem.junit5.AemContextExtension
- a. pom.xml
Choosing the Right AemContext to Speed Up Tests

1. Exactly what is io.wcm.testing.mock.aem.junit5.AemContextExtension?

io.wcm.testing.mock.aem.junit5.AemContextExtension enables you to mock a in-memory AEM JCR, exactly like the AEM instance.

When mocking the JCR instance, you can imagine that this is an empty JCR, with no nodes inside of it, so you will need to use Java to add resources in the mock JCR repository.

Services like the pageManger, tagManger, resourceResolver, etc… will be available in the mock JCR instance.

io.wcm.testing.mock.aem.junit5.AemContextExtension is an extension for JUnit 5 that allows for running AEM (Adobe Experience Manager) unit tests with mocked AEM objects.

It provides a way to set up an AemContext object in a JUnit 5 test class, which gives access to mocked AEM objects such as the ResourceResolver, SlingSettings, and more.

This makes it easier to test code that interacts with AEM without requiring a running AEM instance.

It allows developers to write unit tests that can test their AEM-based code in isolation, without relying on a running AEM instance or a test environment set up with a specific version of AEM.

This extension can be used for testing AEM components, AEM service, AEM workflows and more.

It reduces the time and cost of testing by eliminating the need for a running AEM instance, and allows for faster test execution and more efficient development.

2. What are the use cases for io.wcm.testing.mock.aem.junit5.AemContextExtension

Unit testing AEM-based projects without the need for a running AEM instance
Isolating your tests from the dependencies on a specific AEM version or environment
Mocking specific AEM objects, such as the ResourceResolver or SlingSettings, for more fine-grained control over the test environment
Simplifying the setup and tear-down of AEM-related test objects
Improving the reliability and repeatability of your tests by reducing external dependencies.

Here’s an example of how to use AemContextExtension in a JUnit 5 test class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

import io.wcm.testing.mock.aem.junit5.AemContext;
import io.wcm.testing.mock.aem.junit5.AemContextExtension;
import org.apache.sling.api.resource.Resource;
import org.apache.sling.api.resource.ResourceResolver;

@ExtendWith(AemContextExtension.class)
class MyTest {

private final AemContext context = new AemContext();

@Test
void testMockResourceObjects() {
// create mock resource objects
context.create().resource("/content/object1", "prop1", "value1");
context.create().resource("/content/object2", "prop1", "value2", "prop2", "value3");
context.create().resource("/content/object3", "prop1", "value4", "prop2", "value5", "prop3", "value6");

// get resource resolver
ResourceResolver resourceResolver = context.resourceResolver();

// test object 1
Resource resource1 = resourceResolver.getResource("/content/object1");
assertNotNull(resource1);
assertEquals("value1", resource1.getValueMap().get("prop1", String.class));

// test object 2
Resource resource2 = resourceResolver.getResource("/content/object2");
assertNotNull(resource2);
assertEquals("value2", resource2.getValueMap().get("prop1", String.class));
assertEquals("value3", resource2.getValueMap().get("prop2", String.class));

// test object 3
Resource resource3 = resourceResolver.getResource("/content/object3");
assertNotNull(resource3);
assertEquals("value4", resource3.getValueMap().get("prop1", String.class));
assertEquals("value5", resource3.getValueMap().get("prop2", String.class));
assertEquals("value6", resource3.getValueMap().get("prop3", String.class));
}
}

2a. pom.xml

These dependencies are what is being used in my pom.xml file for the example above.

3 include dependencies:

The first dependency is the “wcm-io-test-context-aem” library which provides the AemContext extension and utility classes for unit testing AEM-based Java code.
The second dependency is “junit-jupiter-api” which provides the JUnit 5 API for writing tests.
The third dependency is “junit-jupiter-engine” which provides the JUnit 5 TestEngine implementation for running tests.

Keep in mind that these versions could be different based on the latest version of the dependencies, you should check the documentation for the latest versions before use… these are my settings.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<dependency>
<groupId>io.wcm.testinggroupId>
<artifactId>wcm-io-test-context-aemartifactId>
<version>3.3.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.junit.jupitergroupId>
<artifactId>junit-jupiter-apiartifactId>
<version>5.7.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.junit.jupitergroupId>
<artifactId>junit-jupiter-engineartifactId>
<version>5.7.0version>
<scope>testscope>
dependency>

3. Choosing the Right AemContext to Speed Up Tests

The AemContextExtension allows for direct injection of the context into test methods, this can speed up test suite execution in cases where certain tests require the use of real JCR due to the use of indexes or other JCR features, while others do not. The more “mocked” the underlying resource resolver is, the faster the context will be. Therefore, it is recommended to use the following contexts in this order if possible:

org.apache.sling.testing.mock.sling.junit5.NoResourceResolverTypeAemContext (fastest)
- NoResourceResolverTypeAemContext is a type of AemContext that is used for tests that do not require a resource resolver.
- When this type of AemContext is injected into a test method, it means that the test will not have access to any resource resolving functionality, such as resolving resources by path or querying the JCR.
- This can be useful for tests that do not rely on any resources and only test pure Java logic.
- This AemContext is the fastest of all the AemContexts because it does not have to instantiate a resource resolver and therefore it is lightweight, and can be useful when running test suites that requires a lot of test cases.
org.apache.sling.testing.mock.sling.junit5.ResourceResolverMockAemContext (default when just AemContext is used)
- ResourceResolverMockAemContext is an extension of AemContext which mocks the AEM resource resolver.
- When you inject an AemContext of this type, it means that the resource resolver used within your test will be a mocked version, rather than the real resource resolver.
- This can be useful for faster test execution and for isolating your tests from external dependencies.
- It is the default context when using AemContext alone.
org.apache.sling.testing.mock.sling.junit5.JcrMockAemContext (slower)
- JcrMockAemContext is an extension of AemContext which mocks the AEM resource resolver.
- Injecting AEMContext of JcrMockAemContext means that the test class is using a mocked version of the JCR for its AEM context; this means that the JCR functionality is being simulated in order to test the functionality of the code being tested, rather than utilizing a real JCR instance.
- This can be useful for testing as it allows for faster execution and a more controlled environment.
- The JcrMockAemContext also allows you to use JCR specific features, such as indexes, in your tests. This is useful when you need to test the functionality of your code that uses JCR indexes.
- This is slower to compared to other AemContext because it simulates a full JCR repository, including the persistence layer. This means that it has to perform more operations and calculations in order to simulate the JCR repository, which can lead to slower test execution times. Additionally, if your tests are using features that require a real JCR repository, such as indexing or searching, this context may be slower as it is still a mocked version of the repository.
org.apache.sling.testing.mock.sling.junit5.JcrOakAemContext (slowest)
- Injecting AEMContext of JcrOakAemContext simulates a real JCR (Java Content Repository) with OakJCR.
- This context is the slowest of all the AemContext options because it uses a real JCR and therefore takes more resources and time to run the test.

1
2
3
4

private final AemContext noResourceResolverTypeAemContext = new AemContext(ResourceResolverType.NONE); // fastest
private final AemContext resourceResolverMockAemContext = new AemContext(ResourceResolverType.RESOURCERESOLVER_MOCK); // default
private final AemContext jcrMockAemContext = new AemContext(ResourceResolverType.JCR_MOCK); // slower
private final AemContext jcrOakAemContext = new AemContext(ResourceResolverType.JCR_OAK); // slowest

It is common to see tests where AemContext is stored in a field in a test class. However, if a single test requires JCR, this can slow down all other tests. With the ability to inject context as a test method parameter, previous tests will be as fast as before.

The post AEM JUNIT5 with io.wcm.testing.mock.aem.junit5.AemContextExtension appeared first on Sourced Code.

Mocking Static Methods in JUNIT5

briankasingli — Sat, 28 Jan 2023 05:12:08 +0000

PowerMock is a Java framework that allows you to unit test code that uses static methods, constructors, and private methods. PowerMock uses a combination of bytecode manipulation and reflection to enable the mocking of these types of methods.

PowerMock is not officially supported by JUnit 5. PowerMock is built on top of EasyMock and provides additional functionality such as the ability to mock static methods, constructors, and private methods. PowerMock uses a different test runner than the one provided by JUnit 5, so it is not directly compatible with JUnit 5.

Alternatively, you can use mockito-inline for inline mocking, it allows you to mock static methods, final classes, and methods, and more.

JUnit 5 provides its own extension model that allows for the creation of custom test runners and the registration of extensions. You could write your own test runner for PowerMock that works with JUnit 5 or use a different mocking framework that is compatible with JUnit 5.

PowerMock is not officially supported by JUnit 5
If you are using JUnit5 and you really need to use Powermock, you could use the powermock-module-junit5 and powermock-api-mockito2 which have support for JUnit5, but it’s not recommended as it’s not officially supported by JUnit5, and to use mockito-inline as suggested.

JUNIT5 Mock Static Method Code Examples

Here’s an example of how to use mockito-inline to mock a static method in JUnit 5. Starting with a Utils class, we displaying an example of us initializing a Utils class with a static method of getString().

Utils.java class
This is a simple utils class used by JAVA, where it has a static method of getString().

1
2
3
4
5

public class Utils {
public static String getString() {
return "Original string";
}
}

MyTest.java class
This is an example of a class utilizing the utils class. As you can see in the code, line:10 && line:11 is performing the mocking mechanism. It is important to note that we are using mockito-inine which introduced Mockito.mockStatic, where we can mock the static method for the Utils class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.mockito.Mockito;

public class MyTest {

@Test
public void testStaticMethod() {
// mock the static method of the Utils class
Mockito.mockStatic(Utils.class);
Mockito.when(Utils.getString()).thenReturn("Mocked string");

// create an instance of the class that calls the static method
MyClass myClass = new MyClass();
assertEquals("Mocked string", myClass.getStringFromUtils());
}
}

pom.xml
These are the maven dependencies being used to get the code working as expected for the JUNIT5 examples above.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<dependency>
<groupId>org.junit.jupitergroupId>
<artifactId>junit-jupiter-apiartifactId>
<version>5.11.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.junit.jupitergroupId>
<artifactId>junit-jupiter-engineartifactId>
<version>5.11.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-coreartifactId>
<version>3.6.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-inlineartifactId>
<version>3.6.0version>
<scope>testscope>
dependency>

The post Mocking Static Methods in JUNIT5 appeared first on Sourced Code.

JUnit 5: Mocking the HttpClient in Java

briankasingli — Sat, 31 Dec 2022 07:01:38 +0000

Unfortunately when building AEM backend logic, the org.apache.http.client.HttpClient is non-trivial to write unit tests. In my case, I scavenged across the net to find a solution where you can make an GET and POST request via HttpClient in particular for AEM, and unit test is performing as expected. In order for me write successful to my servlet, I had to refactor the code. Forcefully, I had to change the org.apache.http.client.HttpClient to org.apache.http.osgi.services.HttpClientBuilderFactory OSGI service; the HttpClientBuilderFactor giving me the HttpClient that I need.

This article will showcase a successful unit test with the doGet and doPost example code. The result of the methods will return a JSON string, which we will mock.

1. Dependencies

Before we begin, I would like to mention the dependencies that I am using to get this code to work (please make sure you are using JUNIT5):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<dependency>
<groupId>io.wcmgroupId>
<artifactId>io.wcm.testing.aem-mock.junit5artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.slinggroupId>
<artifactId>org.apache.sling.models.implartifactId>
exclusion>
<exclusion>
<groupId>org.slf4jgroupId>
<artifactId>slf4j-simpleartifactId>
exclusion>
exclusions>
<scope>testscope>
dependency>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-coreartifactId>
<version>4.1.0version>
<scope>testscope>
dependency>
<dependency>
<groupId>org.mockitogroupId>
<artifactId>mockito-junit-jupiterartifactId>
<version>4.1.0version>
<scope>testscope>
dependency>

2. HttpClientServlet.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

package com.sourcedcode.core.servlets;

import com.adobe.granite.rest.Constants;
import com.drew.lang.annotations.NotNull;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.google.gson.Gson;
import com.google.gson.JsonObject;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.ContentType;
import org.apache.http.entity.StringEntity;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.osgi.services.HttpClientBuilderFactory;
import org.apache.http.util.EntityUtils;
import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.HttpConstants;
import org.apache.sling.api.servlets.SlingAllMethodsServlet;
import org.apache.sling.servlets.annotations.SlingServletResourceTypes;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;

import javax.servlet.Servlet;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.HashMap;
import java.util.Map;

@Component(service = Servlet.class)
@SlingServletResourceTypes(
methods = {HttpConstants.METHOD_GET, HttpConstants.METHOD_POST},
resourceTypes = "sourcedcode/component",
selectors = {"example"},
extensions = {"json"}
)
public class HttpClientServlet extends SlingAllMethodsServlet {

@Reference
private HttpClientBuilderFactory clientBuilderFactory;

@Override
protected void doGet(@NotNull SlingHttpServletRequest request, @NotNull SlingHttpServletResponse response) throws ServletException, IOException {
CloseableHttpClient client = clientBuilderFactory.newBuilder().build();
HttpGet getMethod = new HttpGet("https://dummy.restapiexample.com/api/v1/employee/1");
CloseableHttpResponse httpClientResponse = client.execute(getMethod);
String responseBody = EntityUtils.toString(httpClientResponse.getEntity());
JsonObject jsonObject = new Gson().fromJson(responseBody, JsonObject.class);
response.setStatus(HttpServletResponse.SC_OK);
response.setContentType(Constants.CT_JSON);
response.setCharacterEncoding(StandardCharsets.UTF_8.name());
response.getWriter().write(jsonObject.toString());
}

@Override
protected void doPost(@NotNull SlingHttpServletRequest request, @NotNull SlingHttpServletResponse response) throws ServletException, IOException {
CloseableHttpClient client = clientBuilderFactory.newBuilder().build();
ObjectMapper mapper = new ObjectMapper();
Map<String, String> object = new HashMap<>();
object.put("test", "value");
StringEntity requestData = new StringEntity(
mapper.writeValueAsString(object),
ContentType.APPLICATION_JSON);
HttpPost postMethod = new HttpPost("https://freemeposting.free.beeceptor.com/my/api/path");
postMethod.setEntity(requestData);
postMethod.setHeader("Test", "Test");
CloseableHttpResponse preRenderedResponse = client.execute(postMethod);
String responseBody = EntityUtils.toString(preRenderedResponse.getEntity());
JsonObject jsonObject = new Gson().fromJson(responseBody, JsonObject.class);
response.setStatus(HttpServletResponse.SC_OK);
response.setContentType(Constants.CT_JSON);
response.setCharacterEncoding(StandardCharsets.UTF_8.name());
response.getWriter().write(jsonObject.toString());
}
}

3. HttpClientServletTest.java

In all, the most important line here that you should take a look at is line:60. On this line you can see that I am injecting mocks into the HttpClientBuilderFactory osgi service, which when clientBuilderFactory.newBuilder().build() is being called, the HttpClientBuilderFactory is bring returned in lin:47, which will be the HttpClient itself.

package com.sourcedcode.core.servlets;

import io.wcm.testing.mock.aem.junit5.AemContext;
import io.wcm.testing.mock.aem.junit5.AemContextExtension;
import org.apache.http.HttpEntity;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.osgi.services.HttpClientBuilderFactory;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingAllMethodsServlet;
import org.apache.sling.testing.mock.sling.ResourceResolverType;
import org.apache.sling.testing.mock.sling.servlet.MockSlingHttpServletRequest;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import javax.servlet.ServletException;
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.PrintWriter;

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.*;

@ExtendWith({AemContextExtension.class, MockitoExtension.class})
public class HttpClientServletTest extends SlingAllMethodsServlet {

private final AemContext aemContext = new AemContext(ResourceResolverType.JCR_MOCK);

@Mock
HttpClientBuilderFactory clientBuilderFactory;

@Mock
CloseableHttpClient closeableHttpClientMock;

@Mock
CloseableHttpResponse closeableHttpResponseMock;

@InjectMocks
private HttpClientServlet unitTest = new HttpClientServlet();

@Test
public void testServletDoGet() throws ServletException, IOException {
String responseData = "{status: "success"}";
InputStream anyInputStream = new ByteArrayInputStream(responseData.getBytes());

MockSlingHttpServletRequest request = aemContext.request();
SlingHttpServletResponse response = mock(SlingHttpServletResponse.class);
HttpEntity httpEntityMock = mock(HttpEntity.class);

when(clientBuilderFactory.newBuilder()).thenReturn(mock(HttpClientBuilder.class));
when(clientBuilderFactory.newBuilder().build()).thenReturn(closeableHttpClientMock);
when(closeableHttpClientMock.execute(any())).thenReturn(closeableHttpResponseMock);
when(closeableHttpResponseMock.getEntity()).thenReturn(httpEntityMock);
when(httpEntityMock.getContent()).thenReturn(anyInputStream);
PrintWriter printWriterMock = mock(PrintWriter.class);
when(response.getWriter()).thenReturn(printWriterMock);

aemContext.registerService(HttpClientBuilderFactory.class, clientBuilderFactory);

unitTest.doGet(request, response);
verify(printWriterMock).write(eq("{"status":"success"}"));

}

@Test
public void testServletDoPost() throws ServletException, IOException {
String responseData = "{status: "success"}";
InputStream anyInputStream = new ByteArrayInputStream(responseData.getBytes());

MockSlingHttpServletRequest request = aemContext.request();
SlingHttpServletResponse response = mock(SlingHttpServletResponse.class);
HttpEntity httpEntityMock = mock(HttpEntity.class);

when(clientBuilderFactory.newBuilder()).thenReturn(mock(HttpClientBuilder.class));
when(clientBuilderFactory.newBuilder().build()).thenReturn(closeableHttpClientMock);
when(closeableHttpClientMock.execute(any())).thenReturn(closeableHttpResponseMock);
when(closeableHttpResponseMock.getEntity()).thenReturn(httpEntityMock);
when(httpEntityMock.getContent()).thenReturn(anyInputStream);
PrintWriter printWriterMock = mock(PrintWriter.class);
when(response.getWriter()).thenReturn(printWriterMock);

aemContext.registerService(HttpClientBuilderFactory.class, clientBuilderFactory);

unitTest.doPost(request, response);
verify(printWriterMock).write(eq("{"status":"success"}"));
}
}

The post JUnit 5: Mocking the HttpClient in Java appeared first on Sourced Code.

JUNIT5 Archives - Sourced Code

How to Speed Up Unit Tests in JUnit 5 AEM Projects with SLF4J-NOP

1. Why Disable Logs During Unit Tests?

2. Adding slf4j-nop to Your Project

3. Benchmarks and Examples

4. Further Optimizing AEM Tests

JUNIT 5: ArgumentCaptor with Mockito

Putting ArgumentCaptor to Work: A Real-world Scenario

SearchService.java

SearchServiceTest.java

Benefits and Best Practices

Wrapping Up

JUNIT 5: JCR SQL 2 Unit Tests w/ Sling Servlet

1. What to test for when testing a Servlet or OSGI Service that utilizes the Java, JCR SQL 2 API?

1a. Query String

2b. Results of the Query, Nodes

2. Code Examples

2a. GetPagedByPathServlet.java

2b. GetPagedByPathServletTest.java

JUNIT5: What Exactly is org.mockito.junit.jupiter.MockitoExtension and Sling Model Example

AEM JUNIT5 with io.wcm.testing.mock.aem.junit5.AemContextExtension

1. Exactly what is io.wcm.testing.mock.aem.junit5.AemContextExtension?

2. What are the use cases for io.wcm.testing.mock.aem.junit5.AemContextExtension

2a. pom.xml

3. Choosing the Right AemContext to Speed Up Tests

org.apache.sling.testing.mock.sling.junit5.NoResourceResolverTypeAemContext (fastest)

org.apache.sling.testing.mock.sling.junit5.ResourceResolverMockAemContext (default when just AemContext is used)

org.apache.sling.testing.mock.sling.junit5.JcrMockAemContext (slower)

org.apache.sling.testing.mock.sling.junit5.JcrOakAemContext (slowest)

Mocking Static Methods in JUNIT5

JUNIT5 Mock Static Method Code Examples

JUnit 5: Mocking the HttpClient in Java

1. Dependencies

2. HttpClientServlet.java

3. HttpClientServletTest.java