This is a Technical Challenge submission which consists in developing a two endpoint work timesheet control system. The specification can be found at .\api.yaml.
- IntelliJ Community 2023.1
- Windows 11 22H2
- JDK 18
- Maven 3.9.X
- JAVA_HOME environment set correctly
- Working endpoint (raw logic)
- Fully Matches request and response specifications
- Fully Unit Tested
- Fully Integration Tested
- Working endpoint (raw logic)
- Fully Matches request and response specifications
- Fully Unit Tested
- Fully Integration Tested
Set IliaTechnicalChallengeApplication.class as the running class given a run configuration, or right-click it to run it directly.
Most of the workday punches manual tests cases could be represented in the PunchControllerIntegrationTest.class. It is possible to run it the same way as IliaTechnicalChallengeApplication.class using IntelliJ.
.\mvnw clean spring-boot:run
When the project is running locally, its endpoints will be available at
localhost:8080You can also run all the projects tests using maven wrapper. Please make sure that port 8080 is free.
.\mvnw clean verify
- In a day-to-day basis, this repository commits, branches and PRs would follow and organized issue based structure, like "#123 - Add workday calculation at WorkdayService". For simplicity, all commits were done at the main branch with no protection or checks enabled.
- To maintain standardization in the code base, everything was written in English as the primary language. As the request and response information were in Portuguese, it was used the @JsonProperty annotation for this adjustment;
- It was not considered internationalization and localization as this projects specs, as it would change a lot of projects design decision;
- For maintaining the workday data, an in-memory H2 database was selected, given its easy of configuration and Hibernate/JPA easy of use for the given tasks. After each service run, the database persisted data is cleared;
- Currently, given IntelliJ coverage calculation, the test coverage for lines is at 100%. There are 42 unit and integration tests combined;
- Every class was written using TDD best practices. It was used a similar approach to BDD testing but a specific BDD testing dependency was not added for reducing this project complexity.
- As it was not completely specified, some date and time handling was done using the ISO format, as it is a common date and time format, and it could facilitate API usage for other systems;
- For the workday validations, a design pattern was used, a Chain of Responsibility like structure. Using this pattern, any modifications to the business logic can be easily done, such as refactors, removal or additions.
- Given previous timesheet systems interactions, it was considered that "being at lunch" means that you punched your card twice in a day, one for starting the work journey and one for leaving for lunch;
- There's an important specification missing at the challenge: Do not punch if the actual time is before the last one. This specification was skipped to reducing this project complexity.
- The timesheet calculation consider only workdays which has the required four punches;
- The calculation is based on the count of working weekdays (Monday - Friday) of the specified YearMonth and loads the configuration in the application.yml for the expected duration for each workday and lunch hours;
- The specification was not fully clear if this calculation should be done automatically, like in each punch and saving it to the database, or if it should be done on-demand. For this case, we went with the on-demand approach to reduce this project complexity.
- Tag unit and integration tests for different maven profiles;
- Add functional testing (e.g. using Cucumber);
- Add PIT mutation testing;
- Add pre-commit hook for code styling and static analysis checks;
- Docker the project for easy testing and deployment;
- Use GitHub Actions to CI/CD tasks (code coverage, static analysis, deployment);
- Share Postman automated testing requests collection;