3

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

2 Answers 2

6

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
  • Exactly---integration testing doesn't mean you need real data. 555-55-5555 ought to be just as valid for testing as a real social security number---their form is the same.
    – Kazark
    Commented May 20, 2013 at 19:11
  • Another advantage of not using real data is that you can simulate error conditions that may not exist in your real data. Between privacy concerns (and rules and laws, if applicable) and performance of tests (using mocks/fakes at your unit and integration tests, and a test data database for system level tests), and much greater control over the contents of the test data, this is what I'd recommend.
    – Thomas Owens
    Commented May 20, 2013 at 19:13
0

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..

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.