ij0292

About

A Spring Boot Application to generate tool rental agreements via REST API endpoints. A POST endpoint is available to create a new tool rental agreement, it returns a receipt with the rental information. The provided tool code MUST correlate to an existing tool in the db. The data is stored in a MySQL db.

NOTE

This application was not set up to run entirely outside of tests. It would require config, an external db, etc. that felt out of the scope of this project.

Assumptions

• The checkout date is included as a charge day, the return date is not.
• The checkout date is the beginning date of the rental period.
  • It's unclear if the checkout date can be set in the past or future, or if it literally means "at time of checkout".
  • If it's the latter, then it might not make sense to make it user submitted, it could be generated by the server to ensure accuracy. The only thing needed would then be the user timezone to adjust from now().
• The tools provided are only for test purposes. The SQL could be stored in main resources if it were to be used in production. If the tools were meant to be static across all environments, they could also be created in the Flyway migration.

Choices

• Database tables are set up by Flyway migrations.
• Calculations are stored in the database along with user input. If the calculations were expected to never change, we could theoretically calculate them during a GET or on demand. This would save a little DB space, but it would have issues if the logic were to change, and it would make GETs and other retrievals slower.
  • Doing this also allows someone looking at the DB to easily see the calculations that were made.
• The POST for agreements is under /tools, as it felt like a subresource of tools.
  • This will allow for rental agreement endpoints to be available for other things in the future if need be.
  • It will also allow us to GET rental agreements for a particular tool.
  • If needed, a separate /rental-agreements endpoint could be created if we need a list of all rental agreements regardless of resource.
• Things like repositories for ToolType were not created because they were not used in the application.

Tests

• Tests are run with JUnit 5.

Unit Tests

• Unit tests are run with Mockito.
• Tests were made for service classes.
  • Some very granular methods, like the various calculations, were not tested as they are used in other methods that are tested.
  • All tests provided by requirements are included EXCEPT for ones that required input validation, as that is handled at the Controller layer.
• Tests were made for DateUtil to ensure the date calculations are correct.
  • Tests were not written for simple methods, like date formatting, as they are not complex enough to warrant it.
• A test was made for the response dto to ensure the toString is formatted correctly.
• Tests were NOT made for Controllers, Repositories, Entities, other DTOs, or Mappers.
  • Controllers are tested as part of e2e tests.
  • Nothing in the repositories is complex enough to warrant testing.
  • Entities and DTOs only have setters and getters. Something like MeanBean could be used to test them, but this would only be to up code coverage.
  • Mapper tests seemed a little out of scope of this project, but it's reasonable to add some.

Integration Tests

• For REST APIs, I categorize any test that hits the endpoint and does all the logic as expected as an e2e (end to end) test.
• I did not write any further integration tests, as I felt the e2e tests were sufficient.

e2e Tests

• e2e tests are run SpringBootTest.
• e2e tests use a MySQL test container that is managed by Flyway.
  • A data.sql file is used to populate the db with test data automatically by Spring.
    • I originally intended to have a sql file named in a subdirectory so that multiple can be used for different tests, but I noticed that this SQL was being run after every test and having collision issues, the alternative was to drop the tables and start fresh after each test, but this felt like it would be slower. This is probably doable, but it felt like premature optimization.
    • The data was not loaded via Flyway as I'm not sure if these tools are meant to be static or not.
• e2e tests cover all test scenarios provided.
  • I wrote these before writing the service tests for the same scenarios. Some of these e2e tests are a bit overkill, but since they were already written and the test suite is small enough, if seemed okay to leave them in.
• e2e tests cover additional scenarios, like invalid input and resource not found responses.
• There are some build methods in the e2e tests that aren't particularly useful now, but they could be useful for more granular tests in te future.
  • These would probably move into Util classes at that point, but that felt like overkill for this project.

Possible Improvements

• Add a GET endpoint to retrieve an agreement by id.
• Add a way to generate an agreement without saving it, for example if we wanted to show a preview to the user.
• Add some of the smaller tests written above.
• See if there's a way to do more of the calculation mapping in the mapper. I haven't done a ton of work in MapStruct, I'm sure it's doable.
• Add logging.
• Add more constants to avoid typos.
• Add Javadoc, Swagger, etc.
• Add GET endpoints to look up tools.
• Move common test functions into methods or Util classes to avoid duplication.
• Add comments to flyway, sql files, etc.
• Configure the application to run outside of tests.
• Containerize the application.
• Add a CI/CD pipeline.
• Add branch protections, do proper PRs, etc.