Running & Writing Tests

Reliable testing is crucial for the stability and correctness of the Claim Processing System, especially given its interactions with various components like databases, Kafka, Redis, and external services. This section guides you through running the existing test suite and provides best practices for writing new unit and integration tests.

1. Running Existing Tests

The project uses Maven for build management, and all tests are written using JUnit 5 and Mockito.

1.1. Running All Tests

To execute all unit and integration tests configured in the project, navigate to the project's root directory in your terminal and run the Maven test goal:

mvn test

This command will compile the test sources, run all tests located under src/test/java, and generate a report.

1.2. Running Specific Test Classes

If you need to run tests for a particular component, you can specify the test class using the -Dtest parameter:

mvn test -Dtest=ClaimServiceTest

Replace ClaimServiceTest with the fully qualified class name of the test you wish to run (e.g., com.claim.demo.service.ClaimServiceTest).

1.3. Running Tests from an IDE

Most modern Java IDEs (like IntelliJ IDEA, Eclipse, VS Code with Java extensions) provide integrated support for running JUnit tests. You can right-click on a test class or a specific test method within the IDE and select "Run Test" to execute it.

2. Writing New Tests

When adding new features or modifying existing logic, writing comprehensive tests ensures that your changes behave as expected and do not introduce regressions.

2.1. General Testing Philosophy

Clarity: Tests should be easy to read and understand what they are testing.
Isolation: Unit tests should test a single component in isolation, mocking out its dependencies.
Completeness: Cover successful paths, edge cases, and expected error conditions.
Speed: Tests, especially unit tests, should run quickly to facilitate rapid feedback during development.

2.2. Unit Tests

Unit tests focus on verifying the smallest testable parts of the application, typically individual methods within service classes. They use Mockito to simulate the behavior of dependencies, preventing external factors from influencing the test outcome.

Example: ClaimServiceTest

The src/test/java/com/claim/demo/service/ClaimServiceTest.java file provides a good example of how to write unit tests for service logic.

package com.claim.demo.service;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.ValueOperations;

import com.claim.demo.entity.Claim;
import com.claim.demo.repository.ClaimRepository;

import java.util.Optional;

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

public class ClaimServiceTest {

    @Mock
    private ClaimRepository claimRepository; // Mock the repository dependency

    @Mock
    private KafkaNotificationService kafkaNotificationService; // Mock Kafka service

    @Mock
    private RedisTemplate<String, Object> redisTemplate; // Mock Redis template

    @Mock
    private ValueOperations<String, Object> valueOperations; // Mock ValueOperations for Redis

    @InjectMocks
    private ClaimService claimService; // Inject mocks into the ClaimService instance

    @BeforeEach
    public void setup() {
        MockitoAnnotations.openMocks(this); // Initialize mocks before each test
        // When redisTemplate.opsForValue() is called, return our mocked valueOperations
        when(redisTemplate.opsForValue()).thenReturn(valueOperations);
    }

    @Test
    public void testUpdateClaimStatus_Success() {
        Long claimId = 1L;
        String newStatus = "Approved";
        String userEmail = "user@example.com";
        Claim claim = new Claim();
        claim.setClaimId(claimId);
        claim.setClaimStatus("Pending");
        claim.setEmailId(userEmail);

        // Define mock behavior: when findById is called, return our claim
        when(claimRepository.findById(claimId)).thenReturn(Optional.of(claim));
        // Define mock behavior: when save is called with any Claim, return the same claim
        when(claimRepository.save(any(Claim.class))).thenReturn(claim);
        // Define mock behavior: kafkaNotificationService should do nothing
        doNothing().when(kafkaNotificationService).sendClaimStatusUpdate(anyLong(), anyString(), anyString());
        // Define mock behavior: redisTemplate should set the value
        doNothing().when(valueOperations).set(anyString(), anyString());

        claimService.updateClaimStatus(claimId, newStatus, userEmail);

        // Verify interactions: claimRepository.save was called once with the updated claim
        verify(claimRepository, times(1)).save(claim);
        // Verify interactions: kafkaNotificationService.sendClaimStatusUpdate was called once
        verify(kafkaNotificationService, times(1)).sendClaimStatusUpdate(claimId, newStatus, userEmail);
        // Verify state: the claim's status was updated
        assertEquals(newStatus, claim.getClaimStatus());
        // Verify Redis interaction
        verify(valueOperations, times(1)).set("claimStatus:" + claimId, newStatus);
    }

    @Test
    public void testUpdateClaimStatus_ClaimNotFound_ThrowsException() {
        Long claimId = 1L;
        String newStatus = "Approved";
        String userEmail = "user@example.com";

        // Define mock behavior: findById returns empty optional (claim not found)
        when(claimRepository.findById(claimId)).thenReturn(Optional.empty());

        // Assert that a RuntimeException is thrown
        assertThrows(RuntimeException.class, () ->
            claimService.updateClaimStatus(claimId, newStatus, userEmail)
        );

        // Verify no interactions with save or Kafka if claim not found
        verify(claimRepository, never()).save(any(Claim.class));
        verify(kafkaNotificationService, never()).sendClaimStatusUpdate(anyLong(), anyString(), anyString());
    }

    // ... other tests like testGetClaimStatus, testSubmitClaim, testDeleteClaim
}

Key practices for Unit Tests:

@Mock and @InjectMocks: Use @Mock for dependencies (repositories, other services) and @InjectMocks for the service being tested.
@BeforeEach and MockitoAnnotations.openMocks(this): Initialize mocks before each test to ensure a clean slate.
when().thenReturn() / doNothing().when(): Configure mock behavior to simulate expected outcomes or side effects.
verify(): Assert that specific methods on mock objects were called with the expected arguments and frequency.
assertEquals(), assertThrows(): Assert the return values, state changes, or exceptions thrown by the code under test.

2.3. Integration Tests

Integration tests verify the interaction between multiple components or with external systems (database, Kafka, Redis, external APIs). These tests typically involve launching a subset or the full Spring application context.

Example: ProcessingApplicationTests

The src/test/java/com/claim/demo/ProcessingApplicationTests.java demonstrates a basic integration test that verifies the Spring application context loads successfully.

package com.claim.demo;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;

@SpringBootTest
class ProcessingApplicationTests {

	@Test
	void contextLoads() {
		// This test passes if the Spring application context loads without errors.
		// It's a good baseline for integration testing.
	}

}

Key practices for Integration Tests:

@SpringBootTest: This annotation loads the full Spring application context, making all beans available for testing.
@Autowired: Use this within your test class to inject actual services, repositories, or other components to test their real-world interactions.
Database Testing:
- For repository-layer specific tests, @DataJpaTest can be used. It sets up an in-memory database and only loads JPA-related components, making tests faster.
- For service-layer tests interacting with the database, @SpringBootTest with a test profile pointing to a test database (e.g., H2) is common.
- Consider using @Transactional on test methods to roll back database changes after each test, ensuring test isolation.
Kafka/Redis Integration:
- For more robust integration testing, consider using libraries like Spring-Kafka-Test for Kafka or Testcontainers for both Kafka and Redis. Testcontainers allows you to spin up actual Kafka brokers or Redis instances in Docker containers for your tests.
- Kafka: Verify that messages are correctly published by producers and consumed by listeners.
- Redis: Verify that data is correctly cached, retrieved, and invalidated.
Scheduled Tasks (ClaimBatchService):
- Testing scheduled methods (like processPendingClaims in ClaimBatchService) typically involves disabling actual scheduling for tests and manually invoking the method. You can achieve this by using a test profile that overrides the @EnableScheduling or @Scheduled configurations, or by directly calling the service method in your test.

2.4. Best Practices

Descriptive Naming: Name your test classes [ComponentName]Test (e.g., ClaimServiceTest) and your test methods test[MethodName]_[Scenario]_[ExpectedOutcome] (e.g., testUpdateClaimStatus_Success, testSubmitClaim_InvalidData_ThrowsException).
Arrange-Act-Assert (AAA): Structure your tests into three clear sections:
1. Arrange: Set up the test data and mocks.
2. Act: Execute the code under test.
3. Assert: Verify the results, state changes, and interactions.
Avoid Logic in Tests: Tests should be simple and avoid complex logic. If a test becomes too complex, it might indicate that the code under test needs refactoring.
Refactor Tests: Just like application code, tests also need to be refactored and kept clean. Remove duplication, use helper methods for common setups.

By following these guidelines, you can contribute to a robust and maintainable Claim Processing System.