com.robertboothby.djenni:core

This module holds the core components of the Djenni data generator framework. By itself it provides most of the components to create an efficient end to end data generation framework for a specific domain. It contains the core SupplierBuilder interfaces, implementations for the core Java data types and useful test components. It is intended to be used in conjunction with the source-generator module that will speed up delivery of domain specific data generation and also with common domain modules (TBD) that deliver standard generators for common frameworks such as JAXB.

License	Apache License, Version 2.0
GroupId	com.robertboothby.djenni
ArtifactId	core
Last Version	0.2.0
Release Date	Nov 10, 2019
Type	jar
Description	This module holds the core components of the Djenni data generator framework. By itself it provides most of the components to create an efficient end to end data generation framework for a specific domain. It contains the core SupplierBuilder interfaces, implementations for the core Java data types and useful test components. It is intended to be used in conjunction with the source-generator module that will speed up delivery of domain specific data generation and also with common domain modules (TBD) that deliver standard generators for common frameworks such as JAXB.

Download core

Filename	Size
core-0.2.0.pom
core-0.2.0.jar	73 KB
core-0.2.0-tests.jar	47 KB
core-0.2.0-sources.jar	50 KB
core-0.2.0-javadoc.jar	739 KB

How to add to project

Apache Maven

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

Gradle Groovy

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

Gradle Kotlin

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

Apache Buildr

'com.robertboothby.djenni:core:jar:0.2.0'

Apache Ivy

<dependency org="com.robertboothby.djenni" name="core" rev="0.2.0">
  <artifact name="core" type="jar" />
</dependency>

Groovy Grape

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

Scala SBT

libraryDependencies += "com.robertboothby.djenni" % "core" % "0.2.0"

Leiningen

[com.robertboothby.djenni/core "0.2.0"]

Dependencies

compile (4)

Group / Artifact	Type	Version
com.robertboothby.djenni : util	jar	0.2.0
org.apache.commons : commons-lang3	jar	3.7
org.hamcrest : hamcrest-library	jar	1.3
org.apache.commons : commons-rng-simple	jar	1.0

test (2)

Group / Artifact	Type	Version
junit : junit	jar	4.12
org.mockito : mockito-core	jar	2.18.0

Project Modules

There are no modules declared in this project.

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