Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

    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);

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?

share|improve this question
There are plenty of publicly known valid SSNs. Have you considered testing with those numbers? Wikipedia lists several of them in their article. – Andrew Lewis May 21 '13 at 16:20
up vote 5 down vote accepted

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.

share|improve this answer
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 May 20 '13 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 May 20 '13 at 19:13

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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