🧪 Improve Quality and Coverage of Unit Tests in modernisation-platform-instance-scheduler

[connormaglynn]

User Story

As a Modernisation Platform Engineer
I expect to have a high confidence that unit tests will capture any errors in my code
So that I can be confident my changes do not contain bugs or unintended breaking changes

Value / Purpose

The value of increasing the unit test coverage in the instance scheduler is to ensure engineers can be aware sooner if their changes break anything since unit tests are quick and easy to run locally.

This also has the benefit of being less dependent on our current integration testing process to capture bugs, meaning we can start to move away from this implementation of quality assurance.

Ideally, as well, properly unit testing the code will help highlight areas of the code that can/should be refactored to be more modular, less coupled and ultimately easier to test, read and understand.

Useful Contacts

No response

Additional Information

• Relates to BUG: Instance scheduler fails when action is not supported modernisation-platform-instance-scheduler#138
• Discussion about the integration testing strategy currently implemented can be found in this thread
• You can create a coverage web page of the code by running the following command (although I had to delete the integration test file first)

go test -coverprofile=coverage.out && go tool cover -html="coverage.out"

Proposal / Unknowns

Hypothesis If we... [do a thing] Then... [this will happ]

Proposal A proposal that is something testable, don't worry whether it works or not, it's a place for ideas.

Unknowns Potential pitfalls that could cause the story to expand beyond its original scope. Ideally this section will remain blank.

Definition of Done

• Unit test coverage is ~95% (ideally as close to 100% as possible!)
• Appropriate assertions are in the tests to verify the logic is working as expected (getting the coverage is easy, ensuring the right assertions to correctly test the logic is the hard part!)
• Where appropriate, code has been refactored to be more modular, readable and testable (ideally, do this after writing the tests for that functionality to ensure no breaking changes)
• All code branches of functional code execution have coverage and assertions to ensure functional changes will trigger a failing test
• Another team member has reviewed
• Tests are green

[connormaglynn]

🆙 Update

• Overall code structure has been more modular ♻️ Refactor code into modular files modernisation-platform-instance-scheduler#979
• Unit test coverage has been slightly increased (✨ Add Unit Test For Invalid Action modernisation-platform-instance-scheduler#987, ✨ Add Explicit 500 Error Response When Config Cannot Load modernisation-platform-instance-scheduler#996)
• The EC2 process has decoupled the three processes of stop, start, test 🫧 Bubble Process Logic Upwards For EC2 Instances modernisation-platform-instance-scheduler#990

👀 Remaining Work

• Need to remove all logic of checking whether the action is stop, start or stop in ec2.go and rds.go and have this at the top level (in the handler) - this will aid in the ease of unit testing by lowering the amount of responsibility each function has
• Need to add more unit test coverage to the main.go file. This requires its dependencies to be injectable, which this PR sets up the start of a framework for

📝 Notes

• NA