3 ms·
It occurs to me that this speaks to a more fundamental pain point in software testing. It's so common to write tests that say, in one block of code, "these are
by btown 4y ago
It occurs to me that this speaks to a more fundamental pain point in software testing.
It's so common to write tests that say, in one block of code, "these are the inputs, a function or endpoint is called, and these are the expected outputs." But in theory, every single one of those tests should have variations like "if this exact same input was provided, but with a user with different permissions, as well as a non-logged-in user, the endpoint should fail with a permission error."
But then you get into a quandary: if you want to be able to customize your test code granularly, or have your inputs and outputs generated at runtime, you need to be able to write your test setup code as code, not [{ input, endpoint_name, output }] configurations. But if you need code, then you can accidentally run code that calls things directly without the abstractions that would run it with the extra variations.
At a certain scale, this speaks to needing either static analysis of your testing code, or extremely diligent review processes, beyond simple code coverage.
Does anyone have go-to libraries that deal with this at scale?