Great post! I have experimented with this a little bit and have wrestled with its limitations and enjoyed some of its more surprising benefits. I absolutely ag

Great post! I have experimented with this a little bit and have wrestled with its limitations and enjoyed some of its more surprising benefits. I absolutely agree that tests that do things like “create 3 users, get all users, assert there are 3” is often a less good test than “create 3 users, get all users, assert the 3 created users are in the result set” because it actually tests that you’re not, for some reason, accidentally stripping a key user-attribute when parsing the input. I think a lot of what you’re saying speaks to the importance of writing good tests that don’t only assume the most clean and orderly set of circumstances in which a function can be invoked. For instance, instead of testing update by creating 1 user and then updating them, try creating 3 and updating one, then make sure you’re not, accidentally updating ALL users or nuking some third thing that they all have in common. I will also say that what you’re describing is more of an integration test, and while there’s a strong argument that integration tests are better than units, that it’s not necessarily a novel argument. One thing that I’ve enjoyed with the dirty-data approach is that it makes sure you’re not accidentally doing crazy stuff. I’ve seen oddities where ORMs don’t do the primary key thing correctly, where “cleaning the db” accidentally strips fk relationships, where developers accidentally do something unsafe (e.g. mutable default args in python accidentally store state that they absolutely should not), etc. I think a balanced approach where some tests want some dirt and others are just plain “does it do the thing” tests are good. I will say that I usually prefer relying on my helpers to create some clutter for me, rather than allowing entropy to randomly enter my cases.