Reasons to avoid RandomStringUtils for test data generation

Which problem do we want to solve?

We will try to solve one of the worst practices used on tests at any level: fixed/hard-coded data.

I want to avoid as much as possible any manual pre-action before I can run my tests and, because of that, I try to avoid as well the usage of static files (CSV, TXT, XLS, JSON).

Here we will see a common usage from Java developers: the RamdomStringUItils and how it might not be the best choice for automatic data generation.

By the way, I recommend automatic data generation in the tests using the Test Data Factory approach, and you can find an example here in my blog: Test Data Factory: Why and How to Use.

The examples described here are simple, without the usage of the Test Data Factory, and will show you why the RandomStringUtils might not be the best approach.

Example

We will automatically generate data to a Customer object with the following criteria

To reduce the number of tests, the key point is to generate valid data given the constraints. In a professional environment, we would implement the tests for the edge cases as well.

Think about this Customer data as an object used in any test level (unit, integration, service, UI).

What does the RandomStringUtils class do?

RandomStringUtils is a class from the Apache Commons Lang library that generates random Strings based on different conditions like:

• length
• letters
• numbers
• alphanumeric
• ASCII
• numeric
• print

It’s a static class where you can directly generate any String, so it’s super handy!

See the example below, where you can generate a different set of random data.

What is the result of using RandomStringUtils class?

Let’s first take a look at the code example implementing the usage of RamdonStringUtils:

• line 7 is using the RandomStringUtils.randomNumeric() method to generate an int value and, to make it, possible we are parsing the String into Int using Integer.valueOf()
• lines 8 to 12 use RandomStringUtils.randomAlphanumeric() to generate alphanumeric data
• line 13 has a fixed date as now (today) because RandomStringUtils generates only Strings

The output of the test execution, if we print or inspect the customerData object, is:

We could successfully generate the necessary data! Yay!

What does DataFaker do?

DataFaker is an open-source library based on (actually an improvement of) DataFaker to generate fake data.

I invite you to take a look at the GitHub repo and see the different objects to generate data.

What is the result of using DataFaker?

The code implementation to generate data using the CustomerData class is:

• in line 9, the number() method is in use to generate a random number
• in line 10, the name() method is in use to generate a full name
• in line 11, the company() is in use to generate a profession
• in line 12, the finance() method is in use to generate a valid IBAN for the Netherlands country
• in line 13, the address() method is in use to generate a full street address
• in line 14, the phoneNumber() method is in use to generate a cell phone number
• in line 15, the date() method is in use to generate birthday data for the age between 18 and 90

The output of the test execution, if we print or inspect the customerData object, is:

We could successfully generate the necessary data! But let’s not focus on the differences.

Comparing both approaches

There’re two aspects I would like to consider to choose between one approach or another:

• legibility of future troubleshooting (log analysis)
• easy data creation with different criteria

We can see the main differences comparing the data result side by side (click on the image to expand it):

Legibility of future troubleshooting (analysis)

The regular activity for an engineer that writes code is troubleshooting: we constantly see the logs and debug the application to understand current and future problems in the code.

Now imagine yourself looking at the CustomerData object where the data was filled in with the RandomStringUtils approach: it’s hard to correlate the data you have with a list of objects you might get or even take a look at the data used inside a log file.

Easy data creation in different criteria

For most of the attributes present in the CustomerData class, you can use RandomStringUtils to generate the different criteria. For example, you can easily set 51 characters to the name attribute and expect a failing constraint validation using RandomStringUtils.randomAlphanumeric(51);

For more specialized data, like phone number and date you need a proper library, and DataFaker can generate both data.

In this way, we can make the process easier by adopting one library.

Considerations

Of course, I’d put more emphasis on the DataFaker library because we have almost everything we need to generate data, but it does not exclude a possible necessity to use the RandomStringUtils class or any other class placed in the Apache Commons library.

The main consideration here is the ability to generate all the possible data you need using a single source of truth without reinventing the wheel, as well as the indirect benefits it will show during the troubleshooting process.

Examples

The avoid-random-string-utils project shows a basic example comparing RandomStringUtils vs DataFaker.

The restassured-complete-basic-example project has a factory data class to generate all the necessary data in different conditions. It’s a good real-world example.