Testing Strategy
Relevant source files
The following files were used as context for generating this wiki page:- pom.xml
- src/main/java/com/paymaster/backend/presentation/controller/HomeController.java
- src/main/resources/static/js/app.js
- src/main/resources/templates/customers/form.html
- src/main/resources/templates/contracts/form.html
- src/main/resources/templates/fragments/layout.html
- src/main/resources/templates/error.html
- src/main/resources/templates/customers/list.html
The testing strategy for the PayMaster project, as inferred from the provided source code, is a multi-layered approach combining backend validation via the Spring Boot framework, extensive client-side validation using JavaScript, and a reliance on manual testing for user interface and end-to-end flows. No automated test files (src/test) were provided, so this analysis focuses on the testability features and implicit testing mechanisms built into the application code.
The strategy prioritizes immediate user feedback through client-side checks and robust error handling on both the frontend and backend to ensure data integrity and a stable user experience.
Testing Dependencies and Framework
The project's foundation for testing is established in the pom.xml file, which includes the spring-boot-starter-test dependency. This starter package typically bundles a suite of standard testing libraries for a Spring Boot application.
Sources: pom.xml:67-70
Core Libraries
While no test classes are present, the inclusion of this dependency implies the intended use of the following technologies for writing unit, integration, and end-to-end tests:
| Library | Purpose |
|---|---|
| JUnit 5 | The standard framework for writing and running tests in Java. |
| Spring Test | Provides integration testing support for Spring applications. |
| AssertJ | A fluent assertion library for writing more readable test assertions. |
| Mockito | A mocking framework for creating mock objects in unit tests. |
| H2 Database | An in-memory database used for running tests against a temporary database instance. |
This setup provides a comprehensive toolkit for implementing a full range of automated tests, from isolated unit tests of service logic to full integration tests of the web layer.
Sources: pom.xml:39-42, pom.xml:67-70
Backend Testing Strategy
The backend testing strategy relies heavily on the features provided by the Spring framework for validation and error handling within the controller layer.
Sources: src/main/java/com/paymaster/backend/presentation/controller/HomeController.java
Controller-Level Validation
Data integrity is enforced at the controller level using Java Bean Validation (jakarta.validation). The saveCustomer method in HomeController uses the @Valid annotation to automatically trigger validation on the Customer object.
If validation fails, the BindingResult object captures the errors, and the controller returns the user to the form view, displaying the validation error messages next to the relevant fields. This prevents invalid data from reaching the service layer.
This diagram shows the validation flow for saving a customer.
Exception Handling and Error Pages
Business logic errors, such as a duplicate national ID, are handled via try-catch blocks within the controller methods. When a service throws an IllegalArgumentException, the controller catches it, adds the error message to the model, and returns the user to the form.
For unhandled exceptions or general errors, the application displays a generic error page defined in error.html. This ensures that the user is always presented with a graceful failure message instead of an unstyled server error.
Sources: src/main/java/com/paymaster/backend/presentation/controller/HomeController.java:124-131, src/main/resources/templates/error.html
Frontend Testing Strategy
The frontend implements a robust, user-facing testing and validation layer within app.js. This strategy focuses on providing real-time feedback to the user as they fill out forms, preventing invalid submissions before they reach the server.
Sources: src/main/resources/static/js/app.js
Real-time Form Validation
The FormValidator module in app.js is responsible for client-side validation. It provides utility functions for common validation scenarios.
| Function | Description |
|---|---|
validateNationalCode | Performs a local checksum validation on a 10-digit Iranian national code. |
validateMobile | Validates that a mobile number follows the 09\d{9} format. |
validatePersianDate | Checks if a date string matches the YYYY/MM/DD format and is a valid date. |
These functions are attached to form input events (e.g., blur, input) to give immediate feedback by adding or removing is-valid and is-invalid classes.
Sources: src/main/resources/static/js/app.js:63-111, src/main/resources/static/js/app.js:313-356
Asynchronous Validation (API-Driven)
For fields that require database checks, such as the uniqueness of a national code or mobile number, the frontend performs asynchronous validation.
The setupNationalCodeValidation function in app.js demonstrates this flow:
- An event listener is attached to the
nationalCodeinput field. - A
debouncefunction is used to prevent excessive API calls while the user is typing. - After the user stops typing, an API call is made to
/api/check-national-code. - The server checks for the existence of the code and returns a boolean
validstatus. - The UI is updated with a success or error icon based on the API response.
This sequence diagram illustrates the asynchronous validation for the national code field.
UI and Interaction Testing
The UIComponents module in app.js initializes and manages various Bootstrap components and custom UI elements. This implies a need for manual or automated end-to-end testing to verify:
- Modals: Correct display and focus management.
- Tooltips & Popovers: Proper initialization and display on hover/click.
- Loading Buttons: Submit buttons show a "loading" state on form submission to prevent double-clicks.
- Alerts: Flash messages for success or error are correctly displayed and can be dismissed.
Sources: src/main/resources/static/js/app.js:605-689, src/main/resources/templates/fragments/layout.html:105-122
Manual and Exploratory Testing
Given the absence of an automated test suite in the provided files, the primary method of testing appears to be manual and exploratory. Developers or QA testers would interact with the application through the web interface to verify functionality.
Key areas for manual testing include:
- CRUD Operations: Creating, viewing, updating, and deleting customers and contracts.
- Filtering and Pagination: Ensuring that the filtering on the contracts list and pagination on all list pages work as expected.
-e Calculations: Manually verifying the contract installment calculations on the contract creation form. - Error States: Intentionally submitting invalid data to ensure error messages are displayed correctly.
- Responsive Design: Checking the application's layout and functionality on different screen sizes.
Sources: src/main/resources/templates/customers/list.html, src/main/resources/templates/contracts/list.html, src/main/resources/templates/contracts/form.html
Conclusion
The PayMaster project's testing strategy is pragmatic, leveraging framework features for backend robustness and rich client-side scripts for a responsive user experience. The spring-boot-starter-test dependency indicates an intent for comprehensive automated testing. However, based on the provided files, the current implementation heavily relies on built-in validation mechanisms and manual verification of application flows. The extensive client-side validation in app.js serves as a strong first line of defense against invalid data, reducing the load on the server and improving usability.