What is recommended way to create test data for unit test cases?

Question

I am new to TDD/unit testing.

I am going to write a complex scheduling algorithm in Java. As this module is a core part of our application and there are number of scenarios in it, I want to write unit-test cases for every case.

To compute this schedule, I need to interact with 25-30 entities and each entity, on average, has 10 fields.

Building such huge data for each test cases (maybe I can re-use some of the basic entity data), seems like a exhausting task.

My question is, how do other people solve this problem ?

PS: I want to avoid reading data from database as that would create a dependency.

• Robert Harvey: I want to avoid reading data from database as it will create dependency. -- That's a bad argument. By that logic, we'd never use databases for anything. You have to work out whether the benefit of using a database exceeds the cost of creating a dependency.
• candied_orange: @RobertHarvey actually when crafting a test avoiding the DB helps isolate and speed up the test. So it's a good thing. Unless what you wanted to test was your ability to talk to the DB.
• Robert Harvey: @candied_orange: Sounds like better logic than "it will create a dependency."
• Laiv: @candied_orange and yet there're embedded databases that bring the best of the two approaches. I would happily sacrifice "speed" by "determinism" and "similarity" to production environments. how other people solve this problem? I populate an embedded database with the data required for the test.
• candied_orange: @laiv what are you talking about? I understand embedded DBs to be something that comes with the application that the user doesn't have to install or configure. None of that has to do with DB test-ability. There are in-memory DBs that don't use the filesystem that make testing go really fast but that's not the same thing.

Answer 1

What is recommended way to create test data for unit test cases?

Use a whiteboard

To compute this schedule, I need to interact with 25-30 entities and each entity, on average, have 10 fields.

No. You need to go back to the whiteboard.

You do not need to interact with 250 fields to create one useful test. You need to break down the problem into smaller parts. If you somehow managed to write a test that used 250 fields I certainly wouldn't trust it because I'd have no hope of understanding it.

The point of tests is to help us read code. We break down problems into small manageable chunks because we're lucky if our brains can remember 7 things at the same time. You are simply asking me to remember too much if you want me to understand a test with 250 fields.

That isn't to say we can't have problems that involve 250 fields. Just don't ask me to think about them all at once. Scheduling problems are generally about three things: duration, prerequisites, and resources. Keep that simple model of the problem in mind as you push details away to be dealt with by other abstractions.

That is design. You can't just throw tests at a problem without taking it through design to simplify what you need to test. Once you do that you'll be able to write down cases you want to prove you can handle. That's where your test data comes from.

• Philip Kendall: You do not need to interact with 250 fields to create one useful unit test anyway.

Answer 2

My question is, how other people solve this problem ?

In Java, I normally do this by loading test resources from the classpath.

Most of my projects use maven; so my test resources all live under src/test/resources; within my test harness, I access the data via the InputStream returned by Class::getResourceAsStream.

In most cases where I need to do this, I'll have a sample file already available (data saved from production, for example).

Very rarely, I'll write a program to produce the data that I need, then save that data to a resource file to be loaded by the tests.

If the data is supposed to be immutable, and it is large and not particularly human readable, then I may put the test resource in a jar, which I deploy to my repository, rather than committing the test resource to my source code repository.

• Bhushan: I'll have a sample file already available (data saved from production, for example) How do you format that data in file, I mean you use plain text file or excel-sheet & how do you maintain the relationship between entities?

Answer 3

If you just need to auto-populate your POJOs, you can try Instancio. For example, if you just need to instantiate a class and populate all of its fields with random data, you can do it with a single method call:

Person person = Instancio.create(Person.class);

You can also customise generated values for certain fields:

Person person = Instancio.of(Person.class)
 .generate(field("age"), gen -> gen.ints().range(18, 65))
 .supply(all(LocalDateTime.class), () -> LocalDateTime.now())
 .create();

Disclaimer: I'm the author of this library.

https://github.com/instancio/instancio