((Using "users" as an example to represent one of many record types))
An application with user tracking typically has a User table. Many, if not all, companies mandate that a User record should never be actually deleted. Instead, a discrimating field "isDeleted" should be added. The other possibility is a shadow table that tracks deleted users and its own set of questions which shouldn't be addressed here.
So in general, to retrieve a list of users, I may have a method like so:
public ICollection<User> GetUsers() {
return Users.Where(x => x.isDeleted == false);
}
So I have an SDK which wraps a web service which call domain services which depend on data access which hits my database. The eventuallity is something like so:
public void DeleteUser(int id) {
var user = Users.Where(x => x.id == id).Single();
user.isDeleted = true;
user.SaveDatShiz();
}
So what about my Integration Test? I have an Integration Test something like so:
public void TestUserCreation() {
Dependency.CreateUser(user);
var integratedUser = Dependency.GetUserBySomething(user.Something);
Assert.AreEqual(integratedUser, user, "wut?");
Dependency.DeleteUser(integratedUser.id); //Clean up!
}
The key above is that my Integration Test thinks it is cleaning up, but in reality, my Production Database has three times more fake test users than actual users. The table is SUPER bloated from running Integration Tests on Deployment in a Continuous Deployment environment.
So how do I let my Integration Tests ACTUALLY Delete a user? I'm not asking for a code answer, I'm asking for a architecturally correct answer.
E.G.: Should I create an endpoint that actually does a delete, but require a key that only the Integration Test knows? That seems messy...
E.G.2: Should I get access directly to the production database and run delete queries against it? (Lol, totally lawl no.)
E.G.3: Nobody else worries about this, so I shouldn't (Non-Refundable!!! I mean.. Not Acceptable!!!!)
