Djenni - Data Generator Framework

This is the parent module for all components of the Djenni framework - a test data generation framework that sets out to introduce better practices in test data management and generation. The core goals are: - to reduce the amount of time developers and testers spend manually crafting data - to make tests clearer by only focusing on the key data elements - to make tests even more complete by fuzzing data elements that are not deemed key to the test - to better support later test phases by helping developers to provide data generators suitable for large scale data generation in a thread safe / multi-threadable manner.

License	Apache License, Version 2.0
GroupId	com.robertboothby.djenni
ArtifactId	djenni-parent
Last Version	0.2.0
Release Date	Nov 10, 2019
Type	pom
Description	Djenni - Data Generator Framework This is the parent module for all components of the Djenni framework - a test data generation framework that sets out to introduce better practices in test data management and generation. The core goals are: - to reduce the amount of time developers and testers spend manually crafting data - to make tests clearer by only focusing on the key data elements - to make tests even more complete by fuzzing data elements that are not deemed key to the test - to better support later test phases by helping developers to provide data generators suitable for large scale data generation in a thread safe / multi-threadable manner.
Project URL	https://github.com/RobertBoothby/djenni
Source Code Management	https://github.com/RobertBoothby/djenni

Download djenni-parent

Filename	Size
djenni-parent-0.2.0.pom	6 KB

How to add to project

Apache Maven

<!-- https://jarcasting.com/artifacts/com.robertboothby.djenni/djenni-parent/ -->
<dependency>
    <groupId>com.robertboothby.djenni</groupId>
    <artifactId>djenni-parent</artifactId>
    <version>0.2.0</version>
    <type>pom</type>
</dependency>

Gradle Groovy

// https://jarcasting.com/artifacts/com.robertboothby.djenni/djenni-parent/
implementation 'com.robertboothby.djenni:djenni-parent:0.2.0'

Gradle Kotlin

// https://jarcasting.com/artifacts/com.robertboothby.djenni/djenni-parent/
implementation ("com.robertboothby.djenni:djenni-parent:0.2.0")

Apache Buildr

'com.robertboothby.djenni:djenni-parent:pom:0.2.0'

Apache Ivy

<dependency org="com.robertboothby.djenni" name="djenni-parent" rev="0.2.0">
  <artifact name="djenni-parent" type="pom" />
</dependency>

Groovy Grape

@Grapes(
@Grab(group='com.robertboothby.djenni', module='djenni-parent', version='0.2.0')
)

Scala SBT

libraryDependencies += "com.robertboothby.djenni" % "djenni-parent" % "0.2.0"

Leiningen

[com.robertboothby.djenni/djenni-parent "0.2.0"]

Dependencies

There are no dependencies for this project. It is a standalone project that does not depend on any other jars.

Project Modules

• util
• core
• djenni-source-maven-plugin
• common-generators
• djenni-source-maven-example

Djenni

Test Data Generation Framework

Djenni is the distillation of many years building diverse systems that all needed testing and as a result needed test data.

Why Djenni?

I came to the realisation that in most testing the exact values in the data were irrelevant and needed only to be correct and coherent.

In fact my realisation went further and I realised that there is a major unstated assertion in most testing.

"The test outcome is unaffected by most of the data used in the test"

What does this mean?

In the majority of tests the point of the test is usually affected by one or two values. For example if we are testing a validator that says verifies a vehicle is a bicycle only if it has two wheels then the color, the power-train and the style of the frame should be irrelevant to validation. How do we prove that they are?

We should be able to put random values into the irrelevant data elements in a test and there should be no change in outcome.

In fact this gets worse as often we write tests where even the relevant data values may not have an exact requirement.

For example if we had a similar validator for whether we were dealing with a unicycle or not then any value greater than 1 should produce a false outcome. How can we tell whether this is true if we only ever test with values of 1 and 2?

I actually came across a number of occasions where static data helpers were used by tests that produced the same objects with the same data and when this data was changed many of the tests broke in unexpected ways. Worse I came across code that passed all the tests fine using the fixed data set but broke completely when the code was used in the real world.

Djenni is designed to make it easy to set up test data for all levels of testing and effectively assert which test data is irrelevant to the outome and which data matters.

Djenni also makes it easy to generate large volumes of test data for rich domains and can scale well to support everything from unit testing to large scale non-functional testing.

The Core Pattern

Djenni is built around the concept of a "Supplier" and a "SupplierBuilder".

The Supplier is the ultimate source of test data. Suppliers produce the objects required by the tests. These objects composed of other objects and in the same way most generators are composed of other generators. When a Supplier is used to generate an object, it used other Suppliers to generate the object's fields which themselves may be composed of other Suppliers and so on.

Suppliers should typically be immutable so that they are thread safe.

The SupplierBuilder makes it easy to configure and build instances of its associated Supplier. SupplierBuilders are mutable and are not thread safe.

Once you have used the SupplierBuilder to configure and build your Supplier, you can generate as many instances of your test object as you want, usually on as many threads as you want.

By implementing your own Suppliers and SupplierBuilders you can rapidly build up a data generation suite for your entire domain that will make testing a lot easier.

In addition Djenni contains a Maven plugin that can generate a lot of the Suppliers and SupplierBuilders for your domain.

Versions

Version
0.2.0 Nov 10, 2019
0.1.0 Jun 2, 2019