Creating mock data for software testing

• Download sample - 19.7 KB

Introduction

I'am developing MockData library as a .Net's tool to automatically generate in-memory different "fake data" format as Company Name or Person Name. I wrote this post to share my idea and to get feedback from other developers about how enhance features, I've still planned more features as financial data class generator, localization, export the data in SQL Insert Script file or CSV files. I hope you will join me.  

Background

If you are developing an application, you will want to make sure you are testing it under conditions that closely simulate a production environment. In production, you will have an army of users banging away at your app and filling your database with data, which puts stress on your code. I you are hand-entering data into a test environment one record at time using the UI, you are never going to build up the volume and variety of data that your app accumulate in a few days in production. Worse, the data you enter will be biased towards you are own usage patterns and won't match real-world usage, leaving important bugs undiscovered. Some application frameworks, like as Ruby on Rails, have great data mocking libraries. But not everyone is a programmer, has time to learn a new framework, or is at liberty to adopt a new platform.

Solution  

This post introduces a solution for this topic.  MockData allows you to quickly and easily generate large amounts of randomly generated test data based on your own specs which you can then load directly into your classes for test environment. 

Using the code 

I suppose we have the following class: 

public class Person
{
   public int ID { get; set; }
   public String FirstName { get; set; }
   public String LastName { get; set; }
   public String Address { get; set; }
   public String City { get; set; }
   public String ZipCode { get; set; }
   public String Country { get; set; }
   public bool Status { get; set; }
   public String Details { get; set; }
}

Using MockData we can write the following class :

public static class DummyData
{
    public static IList<Person> GetDataPerson(int number)
    {
        int personIdIncrement = 1;
        return Enumerable.Range(0,number).Select(o =>  new Person
	{
	   ID = personIdIncrement++ ,
           FirstName = MockData.Person.FirstName(),				
           LastName = MockData.Person.Surname(),
	   Address = MockData.Address.StreetAddress(),
	   City = MockData.Address.City(),
	   ZipCode = MockData.Address.ZipCode(),
	   Country = MockData.Address.DefaultCountry(),
	   Status = new Random().Next(0, 2) == 1 ? true : false,
	   Details = MockData.Lorem.Paragraph(1)
	   }).ToList();
	}
    }
}

where number is the number of record to generate in the list. We can write :

List<Person> list = DummyData.GetDataPerson(300);

that returns a list with 300 records of the type Person. At the moment MockData has the following static classes with related methods: 

• Address
  • City
  • Country
  • DefaultCountry
  • State
  • StateAbbr
  • ZipCode
• Company
  • BS
  • Name
  • CatchPhrases
• Internet
  • Email
  • FreeEmail
  • UserName
  • DomainName
  • DomainWord
• Lorem
  • Words
  • GetFirstWord
  • Sentence
  • Paragraph
  • Paragraphs
• Person
  • FirstName
  • Surname
  • FullName
• Product
  • Department
  • ListDepartment
  • ProductName
• Utils
  • Boolean
  • RandomDate 

Points of Interest

When your test database is filled with realistic looking data, you'll be more engaged as a tester. When you demonstrate new features to others, they'll understand them faster. Real data is varied and will contain characters that may not play nice with your code, such as apostrophes, or unicode characters from other languages. Testing with realistic data will make your app more robust because you'll catch errors that are likely to occur in production before release day. I am still developing the tool, with more features as financial data class generator, localization, export the data in SQL Insert Script file or CSV file. 

Next Step

I am exploring enterprise design patterns in N-Layered application looking at Unit Test Design Development and Integration Tests. In my experience when our classes deal with data, we need to use fake data in our unit test. A unit test should do exactly as the name implies and test 'One Unit'. If I am testing a controller I forget all about the data access. I should be removing all of the calls to database context in my mind and replacing them with a black box method call as if those operations were unknown to me. For example in a MVC application we can use the repository pattern. I have a repository, say Product<vars>Repository : IProductRepository</vars><vars>, which will perform all of my product database operations. If I were to test my controllers would I want the tests to test my repository, my database access, and the controller logic itself? Of course not! There are many 'units' in this pipeline. What you want to do is create a fake repository with fake data which implements IProductRepository to allow you to test the controller logic in isolation. If I wanted to test the ProductRepository logic, how would I do that? My opinion is that the easiest way is to use a fake datasource. This will allow me to make sure that when I'm trying to get a user by ID, it actually gets the user by ID and so forth. But this is the topic of my next article.

History

I've just released a beta version 0.0.6 and published it on NuGet. I hope you will join me with your feedback and your suggests  

To install Mock Data Generator, run the following command in the Package Manager Console