2

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.

  • 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. – Robert Harvey Dec 1 '18 at 15:46
  • 1
    @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. – candied_orange Dec 3 '18 at 2:54
  • @candied_orange: Sounds like better logic than "it will create a dependency." – Robert Harvey Dec 3 '18 at 2:55
  • @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. – Laiv Dec 3 '18 at 8:17
  • @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. – candied_orange Dec 3 '18 at 8:29
7

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.

  • 1
    You do not need to interact with 250 fields to create one useful unit test anyway. – Philip Kendall Dec 1 '18 at 15:48
0

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.

  • 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? – Bhushan Dec 1 '18 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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