Why test setup data doesn't always need to be perfect

Last week, I was reviewing an integration test in one of Aaron's pull requests. The test was for a listener that would notify an administrator when a user of a lower-permission role modified a client record.

Always with an eye for detail, I noticed that Aaron set up the test with a user having a very-low permission role, one that didn't even have enough permission to modify the client record in the first place.

I called this out as a nitpick and suggested he update the test setup to the expected user role that would be making this change.

Aaron's response was so good, that I'm sharing it (lightly edited) as today's tip:

Technically correct yes - but this is an integration test. I'm testing the specific logic in the listener, which sometimes is tested with invalid business scenarios. The reason we do this is multiple layers of protection. What if the first layer of checks preventing access to this user role fails? We still have the next level, which is built into the listener itself - not to send a notification. In integration tests, you sometimes will put something unexpected just to confirm that the code you're testing, in isolation, functions in all extreme cases.

I liked his reminder that tests don't always have to be "real world" data scenarios. Sometimes there is value in testing a scenario that should never happen, just to make sure our logic still performs as expected.

Here to help,

Joel

P.S. If your project could benefit from an outside code review, get in touch and we can discuss the details.