Regardless of the amount of work involved, high-level use-case driven integration tests are the most valuable of all tests. These are the ones that test something the user will do, and don't rely on any short-cuts in the system (though may skip the top-level UI and work on the front-end API instead).
Nobody cares if the modules work on their own if the service as a whole is failing.
Lower-level tests, unit tests, module tests, etc. are all great tools for debugging, and to catch errors early, but are not substitutes for high-level use-case tests.
You can reduce some coverage at the highest level, by only testing a single path through each module, and not testing all variants. This is then backed by more detailed module tests. It's a good way to lower cost without a significant loss of use-case testing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Regardless of the amount of work involved, high-level use-case driven integration tests are the most valuable of all tests. These are the ones that test something the user will do, and don't rely on any short-cuts in the system (though may skip the top-level UI and work on the front-end API instead).
Nobody cares if the modules work on their own if the service as a whole is failing.
Lower-level tests, unit tests, module tests, etc. are all great tools for debugging, and to catch errors early, but are not substitutes for high-level use-case tests.
You can reduce some coverage at the highest level, by only testing a single path through each module, and not testing all variants. This is then backed by more detailed module tests. It's a good way to lower cost without a significant loss of use-case testing.