⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma

Tick the checkbox if you understand [x]:

• I have read and understand the pull request rules.

Description

This issue is meant as a discussion.

I have thought a bunch about how our monitors can be tested and have come to the conclusion that for most monitors, testcontainers seem like a good fit.
Testing this part would allow us to merged PRs like #4445 or #4393 without the risk or the level of manual verification required.

Things that we should discuss:

• should new monitors be tested like this
• does addition of these tests add additional value? How important/is this important? (=> "do we want this? if yes, which merge slot")

Type of change

Please delete any options that are not relevant.

• New feature (non-breaking change which adds functionality)
• Other
• This change requires a documentation update

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
• My changes generates no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

<- screenshot of testcases passing ->