I am trying to develop a series of unit tests for a production system that are dependent on a person’s social security number. While I am more than comfortable hard coding a clearly bad social security number to test for failure, I’m uneasy about including one that is good for proper (and passing) results. The following is a simplified test that I’m using:
[TestMethod]
public void API_Hours_Get()
{
var controller = new HoursController();
var employee = new EmployeeController();
var badResult = controller.Get(123124569);
var goodResult = controller.Get(employee.GetEmployeeByUserId("Username").First().SSNumber);
Assert.IsFalse(badResult.Any());
Assert.IsTrue(goodResult.Any());
}
This test passes just fine and gives me the results I want. But, from my understanding, it is an integration test. From a best practices perspective, is this substitute okay for my test suite and just ignore the fact that I don’t have a ‘pure’ unit test for the SSN-dependent modules or is there a better approach for situations like this?
1
A better approach for this sort of thing is to create fake/test data that is operationally real enough without getting into issues like using customers SSNs and email addresses. You can then write the entire test suite against fake data — and do things like simulate various real operational bugs across the way.
Looking at the code I think you’ve got some way to go here — it looks like you aren’t even setup for dependency injection which is the gateway drug to this sort of thing.
2
If you are injecting a repository then you can write tests to your hearts content without worrying about whether the data is real.
Remember what it is you are testing!
You are testing an atomic unit of functionality. Whether the SSN is real doesn’t matter, it’s whether the method you are testing handles it correctly. i.e will it reject one with too many/too few digits, will it reject a null entry etc..