verify() for interaction verification in JUnit - Framework Patterns

Framework Mode - verify() for interaction verification

Folder Structure

src/
└── test/
    └── java/
        └── com/
            └── example/
                ├── pages/
                │   └── LoginPage.java
                ├── tests/
                │   └── LoginTest.java
                ├── utils/
                │   └── WebDriverFactory.java
                └── mocks/
                    └── UserServiceMock.java
    

Test Framework Layers

• Driver Layer: Manages WebDriver instances (e.g., WebDriverFactory.java).
• Page Objects: Encapsulate UI elements and actions (e.g., LoginPage.java).
• Tests: JUnit test classes that use page objects and verify interactions (e.g., LoginTest.java).
• Mocks/Stubs: Simulate dependencies for interaction verification (e.g., UserServiceMock.java).
• Utilities: Helper classes for common tasks like waits, logging.

Configuration Patterns

• Environment Properties: Use src/test/resources/config.properties to store URLs, credentials.
• Browser Setup: Configure browser type and options in WebDriverFactory.java.
• Credentials Management: Store sensitive data securely, load via environment variables or encrypted files.
• Mock Setup: Initialize mocks in test setup methods to verify interactions.

Test Reporting and CI/CD Integration

• Use JUnit reports (XML) for test results.
• Integrate with CI tools like Jenkins or GitHub Actions to run tests on each commit.
• Use plugins like Surefire or Allure for readable HTML reports.
• Include interaction verification results in reports to confirm expected method calls.

Best Practices for verify() Interaction Verification

1. Use Mockito or similar libraries: For verifying method calls on mocks.
2. Keep verification focused: Verify only relevant interactions to avoid brittle tests.
3. Use descriptive verification messages: To clarify what interaction is expected.
4. Separate interaction verification from state verification: To keep tests clear.
5. Reset mocks between tests: To avoid cross-test interference.

Self Check

Where in this folder structure would you add a new mock class to verify interactions with a payment service?

Key Result

Use mocks and verify() calls in JUnit tests to confirm expected interactions with dependencies.

Practice

1. What is the main purpose of verify() in JUnit testing with mocks?

easy

A. To create a mock object

B. To check if a method was called on a mock object

C. To assert the return value of a method

D. To initialize test data before tests run

Solution

1. Step 1: Understand the role of verify()

   verify() is used to check interactions with mock objects, specifically if certain methods were called.

2. Step 2: Differentiate from other mock-related actions

   Creating mocks is done by mock(), asserting return values is done by assertEquals(), and initializing data is unrelated to verify().

3. Final Answer:

   To check if a method was called on a mock object -> Option B

4. Quick Check:

   verify() checks method calls = B [OK]

Hint: Remember: verify() confirms method calls on mocks [OK]

Common Mistakes:

• Confusing verify() with mock() creation
• Using verify() to check return values
• Thinking verify() initializes test data

2. Which of the following is the correct syntax to verify that method save() was called exactly once on a mock object repository?

easy

A. verify(repository).times(1).save();

B. verify(repository).save(1);

C. verify(repository, times(1)).save();

D. verify(repository).calledOnce(save());

Solution

1. Step 1: Recall correct verify() syntax

   The correct syntax uses verify(mockObject, times(n)).method() to check method call count.

2. Step 2: Match options to syntax

   verify(repository, times(1)).save(); matches the correct syntax. Options B, C, and D use invalid or non-existent methods.

3. Final Answer:

   verify(repository, times(1)).save(); -> Option C

4. Quick Check:

   verify(mock, times(1)).method() = A [OK]

Hint: Use verify(mock, times(1)).method() to check single call [OK]

Common Mistakes:

• Writing times(1) after method call
• Passing call count as method argument
• Using non-existent verify methods

3. Given the following code snippet, what will happen when the test runs?

MyService service = mock(MyService.class);
service.process();
verify(service, times(2)).process();

medium

A. Test fails because process() was called only once

B. Test passes because verify() ignores call count

C. Test fails due to syntax error in verify()

D. Test passes because process() was called twice

Solution

1. Step 1: Count method calls on mock

   The method process() is called once on service.

2. Step 2: Check verify() expectation

   The verify expects process() to be called twice (times(2)), but it was called once.

3. Final Answer:

   Test fails because process() was called only once -> Option A

4. Quick Check:

   verify times(2) but called once = D [OK]

Hint: Count actual calls before verify times(n) check [OK]

Common Mistakes:

• Assuming verify ignores call count
• Confusing times(2) with atLeast(2)
• Thinking one call satisfies times(2)

4. Identify the error in this test code snippet:

List<String> list = mock(List.class);
verify(list).add("item");
list.add("item");

medium

A. No error, code is correct

B. Missing times() argument in verify()

C. Incorrect mock creation syntax

D. verify() is called before the method call on the mock

Solution

1. Step 1: Understand verify() checks past calls

   verify() checks if a method was called before it is invoked.

2. Step 2: Check order of calls

   Here, verify() is called before list.add("item"), so no call happened yet to verify.

3. Final Answer:

   verify() is called before the method call on the mock -> Option D

4. Quick Check:

   verify() must follow method call [OK]

Hint: Always call method before verify() to check it [OK]

Common Mistakes:

• Calling verify() before method invocation
• Assuming verify() can predict future calls
• Ignoring call order in tests

5. You want to verify that a method updateStatus(String status) was called exactly once with argument "ACTIVE" on a mock userService. Which code snippet correctly achieves this?

hard

A. verify(userService, times(1)).updateStatus("ACTIVE");

B. verify(userService).updateStatus(anyString());

C. verify(userService, times(1)).updateStatus();

D. verify(userService, times(1)).updateStatus(anyString());

Solution

1. Step 1: Use verify() with times(1) for exact call count

   To check exactly one call, use times(1) in verify.

2. Step 2: Match method call with exact argument

   Pass the exact argument "ACTIVE" inside the method call in verify.

3. Step 3: Evaluate options

   verify(userService, times(1)).updateStatus("ACTIVE"); matches both call count and argument. verify(userService).updateStatus(anyString()); allows any string, not exact. verify(userService, times(1)).updateStatus(); misses argument. verify(userService, times(1)).updateStatus(anyString()); uses times(1) but anyString() matches any argument, not specifically "ACTIVE".

4. Final Answer:

   verify(userService, times(1)).updateStatus("ACTIVE"); -> Option A

5. Quick Check:

   verify with times(1) and exact arg = C [OK]

Hint: Use times(1) and exact argument in verify() [OK]

Common Mistakes:

• Using anyString() instead of exact argument
• Omitting times(1) for call count
• Calling verify() without arguments