Automated Testing Overview
Relevant source files
The following files were used as context for generating this wiki page:
- Part1/API/src/test/java/com/example/api/ApiApplicationTests.java
- Part1/API/src/test/java/com/example/api/EmployeeControllerTest.java
- Part1/API/src/test/java/com/example/api/EmployeeServiceTest.java
- Part1/API/src/test/java/com/example/api/DepartmentServiceTest.java
- Part1/API/src/main/java/com/example/api/controller/EmployeeController.java
- Part1/API/src/main/java/com/example/api/service/EmployeeService.java
- README.md
The automated testing framework for the SafeDispatch HQ Administration API is designed to ensure the reliability and correctness of employee management, department operations, and business logic such as promotions. The suite leverages Java-based testing tools to validate both individual units of code and the integration of the Spring Boot application context.
The testing strategy focuses on high-coverage unit tests for controllers and services, utilizing mocking to isolate components. This ensures that validation logic, such as tenure requirements for promotions or budget constraints for departments, is strictly enforced before deployment.
Sources: README.md, Part1/API/src/test/java/com/example/api/ApiApplicationTests.java:1-13
Testing Architecture
The project employs a layered testing approach using JUnit 5 and Mockito. This architecture separates the validation of web-layer logic from service-layer business rules.
Component Breakdown
- SpringBootTest: Used for integration testing to ensure the application context loads correctly.
- Mockito Extension: Applied to unit tests to mock repository dependencies, allowing for isolated testing of Controllers and Services without a database.
- Mocked Repositories:
EmployeeRepositoryandDepartmentRepositoryare mocked to simulate data persistence and retrieval.
The diagram illustrates how different test classes target specific layers of the application while mocking data access.
Sources: Part1/API/src/test/java/com/example/api/EmployeeControllerTest.java:23-35, Part1/API/src/test/java/com/example/api/EmployeeServiceTest.java:21-25
Unit Testing Logic
Employee Management and Promotion
Testing for the EmployeeController and EmployeeService focuses heavily on the "Promotion" business logic. This includes validating that an employee must have started more than 6 months ago and that their salary is increased by 10% upon successful promotion.
| Test Case | Target Component | Expected Outcome |
|---|---|---|
promoteEmployee_shouldIncreaseSalary | Service | Salary increases by 10% for eligible employees. |
promoteEmployee_ShouldThrow400 | Controller | Returns 400 Bad Request if tenure < 6 months. |
promoteEmployee_ShouldThrow404 | Controller | Returns 404 Not Found if employee ID does not exist. |
createDepartment_shouldThrow | Service | Throws error if budget is non-positive. |
Sources: Part1/API/src/test/java/com/example/api/EmployeeControllerTest.java:70-100, Part1/API/src/test/java/com/example/api/EmployeeServiceTest.java:49-65
Promotion Sequence Validation
The following sequence diagram represents the logic validated during a promotion test case, where the system checks eligibility before applying updates.
This diagram depicts the flow of logic tested in EmployeeServiceTest to ensure salary and role updates occur only for eligible staff.
Sources: Part1/API/src/main/java/com/example/api/service/EmployeeService.java:48-68, Part1/API/src/test/java/com/example/api/EmployeeServiceTest.java:49-65
Department and Validation Testing
Testing for departments ensures that data integrity constraints are met at the service level, specifically regarding financial budgets.
- Budget Validation:
DepartmentServiceTestconfirms that any attempt to create a department with a budget of zero or less results in aRuntimeExceptionorIllegalArgumentException. - Filtering Logic: Tests in
EmployeeControllerTestverify that the system can correctly filter lists of employees by department name via thefindByDepartmentNamerepository method.
Sources: Part1/API/src/test/java/com/example/api/DepartmentServiceTest.java:23-33, Part1/API/src/test/java/com/example/api/EmployeeControllerTest.java:154-161
Execution and CI/CD
The project utilizes the Gradle wrapper for test execution. Tests can be run locally using the gradlew script. The project is also configured to integrate with GitLab CI/CD for automated test execution upon code submission.
# Running tests via Gradle Wrapper
./gradlew test
Sources: Part1/API/gradlew.bat:1-89, README.md
Summary
The automated testing suite provides a robust safety net for the HQ Administration API. By covering critical business paths—such as the 6-month promotion rule and department budget validation—the tests ensure that changes to the codebase do not introduce regressions in core administrative logic. The use of Mockito allows these tests to run quickly and reliably without external dependencies.