Service Testing and GitHub Testing Action Workflow

[dburkhart07]

ℹ️ Issue

Closes #98 #99,

📝 Description

For this PR, I used the orders.service.spec.ts file to show an example of how to setup the service testing to actually use a local database representation for testing. The testing follows these steps:

• Populate database with schemas
• Populate schemas with dummy data
• Run a test
• Clean up dummy data
• Repopulate, and repeat testing

This was all accomplished by creating a DataSourceOptions object, which utilizes the database configurations in the .env file to run all of the migrations that we need to properly spin up an accurate database. We then utilize his data source in each of our service tests so they can properly connect to the test database, and run the above steps.

With this change, we now no longer need any form of mocking in the service, and can just call the database normally, like we have been doing in the service functions. NOTE: It is important that the data we use though matches the data from the CreateDummyData migration. Therefore, it is crucial that we are very aware of the changes we make to this migration moving forward, so that we are not breaking other tests.

I also setup a GitHub action workflow to setup the exact dependencies and perform this workflow automatically on any pull request or push made to the repository.

✔️ Verification

I made sure that all tests passed both locally, and on GitHub actions. To test (which the reviewer should do), follow these steps:

• Create a local database called "securing-safe-food-test". NOTE:* You do not need to populate it with tables, as the testing will populate it for you. The GitHub action workflow will spin up a database on its own, so the testing on github will work even if you did not create this database. This is solely for the purpose of being able to test it locally.
• Create a new field in the .env file (this is needed for both GH actions and local testing) called DATABASE_NAME_TEST and assign it to "securing-safe-food-test". This will allow the specific database to be affected, rather than the one we are using in development.
• Run the test with npx jest, and observe that all of the tests pass.

🏕️ (Optional) Future Work / Notes

• Perhaps better for a future ticket, but we could consider adjusting the workflow that npx jest performs to spin up a local database for us as well (just like GH actions). This would make it so we never need to create a separate database, but rather just need to provide the name that we want in the .env file.
• IMPORTANT NOTE: The DataSourceOptions need to be properly maintained from here on out. Whenever we make a migration or add it to the typeorm.ts file, we need to do the same with the typeormTestDataSource.ts file as well. It should be pretty self-explanatory on how to do it based on the structure.
• Now that we have these workflows in place, it brings up a good point that I believe there may be something wrong with our ci-cd.yml file (not sure if we are actually using that).