Testing Strategy

The testing strategy for the Dashboard Task Management (DTM) system focuses on ensuring data integrity, enforcing role-based access control (RBAC), and validating complex business logic such as task status automation and file handling. The backend is built using Spring Boot 3.2.5, leveraging Spring Data JPA for persistence and Spring Security for authorization.

The system's reliability is maintained through a combination of unit and integration testing support provided by the Spring Boot Starter Test suite. Key areas of validation include service-layer logic, entity lifecycle management, and secure API interactions across various user roles (ADMIN, MANAGER, PM, TEAM).

Sources: pom.xml:13-18, pom.xml:91-95, README.md:1-15

Backend Testing Infrastructure

The project utilizes standard Java testing frameworks integrated via Maven. The pom.xml defines the necessary dependencies for executing tests within the Spring context.

Sources: pom.xml:76-80, pom.xml:91-95

Service Layer Validation Logic

Testing at the service layer involves verifying business rules, especially those concerning multi-role access. Each service implementation includes internal validation methods that must be covered by test cases.

Access Control Verification

The TaskService, SubtaskService, and CommentService implement strict validateTaskAccess or validateTaskScope methods. Tests must ensure that:

• ADMIN has unrestricted access to all entities.
• MANAGER only accesses tasks within their assigned department.
• PM (Project Manager) is restricted to their specific projects.
• TEAM members can only view or interact with tasks to which they are assigned.

Automated Status Recalculation

A critical part of the testing strategy is validating the "Automated Status Update" logic found in the SubtaskService. Tests must verify that a parent task's status automatically transitions based on subtask completion.

Sources: src/main/java/com/example/demo/services/SubtaskService.java:164-185

Data Integrity and History Tracking

The system tracks every change to a task's fields. Testing must confirm that the recordHistory function correctly persists changes to the TaskHistoryRepository only when values actually change.

File Handling and Security Testing

The AttachmentService requires specific test scenarios for file uploads and entity binding. Tests must simulate various file types and sizes to enforce the 10MB limit and allowed MIME types.

Attachment Validation Criteria

• Size Constraint: Ensure files > 10MB throw IllegalArgumentException.
• Type Constraint: Verify only specific types (e.g., PDF, JPEG, PNG, ZIP) are accepted.
• Two-Step Upload: Test the "upload to temp" then "bind to entity" workflow.
• Deletion Rules: Verify that only ADMINs or the original uploader can delete a file.

Sources: src/main/java/com/example/demo/services/AttachmentService.java:55-70, src/main/java/com/example/demo/services/AttachmentService.java:154-180

Conclusion

The testing strategy for DTM focuses heavily on the service layer where the intersection of role-based security and automated business logic occurs. By validating the interaction between TaskService, SubtaskService, and NotificationService, the project ensures that state changes are correctly propagated, recorded in history, and communicated to the relevant team members.