How to override default settings¶
Introduction¶
Out of the box, Instancio is pre-configured with "sensible defaults". For example, when populating an object it will set fields to non-null values, create non-empty collections, generate positive numbers, etc. For cases where these defaults are not acceptable they can be modified as follows:
- globally, using a configuration file
- per test class using settings injection
- per object using the API
This article provides on overview of how to achieve the above goals.
Settings API and default values¶
Instancio configuration is encapsulated by the Settings class which provides the API for modifying settings at runtime. This class is essentially a map of SettingKey objects and their values. A setting key represents a configuration item. It has a default value and a property name that can be used in a configuration file. The complete list of keys can be found in the Keys Javadoc. The following are a few examples:
Keys.COLLECTION_MAX_SIZE
- specifies maximum size for collections- default value:
6
- property name:
collection.max.size
- default value:
Keys.INTEGER_MIN
- specifies minimum value for integers- default value:
1
- property name:
integer.min
- default value:
Keys.STRING_NULLABLE
- specifies whether anull
can be generated for String type- default value:
false
- property name:
string.nullable
- default value:
The Settings
class provides two static methods for creating an instance:
Settings.create()
returns a new instance of blank settingsSettings.defaults()
returns a new instance containing default settings
If no custom settings are provided, Instancio will use default settings as returned by Settings.defaults()
.
Overriding settings per object¶
Settings can be customised per object using the Settings
class. For example, the following snippet creates a person allowing null
and empty strings to be generated:
Example of custom settings per object | |
---|---|
Overriding settings per test class¶
Using InstancioExtension
with JUnit 5 allows injecting settings into a test class. This can be achieved by annotating the Settings
field with @WithSettings
.
The benefit of this approach is that all test methods within the class will use the specified settings. It is more concise as there is no need to call withSettings(settings)
manually on each object.
Overriding settings globally using instancio.properties
¶
Overriding settings globally can be done by placing a file named instancio.properties
on the classpath. Instancio loads this file automatically and uses its values to override the defaults. For example, assuming we have the following file:
all integers generated by Instancio will be within the given range.
A sample properties file with available keys is provided in the user guide.
Configuration precedence¶
Since there are three ways to provide configuration, Instancio has the following precedence rules when resolving configuration values. From lowest to highest:
- Configuration from
instancio.properties
- Configuration from
@WithSettings
- Configuration from
withSettings()
As an example, assume we have this configuration file on the classpath:
The properties file is loaded automatically from the classpath. Therefore the following snippet will generate a number in the 10..99 range.
Next we will modify the above class to override the configuration by injecting Settings
into the test class:
Since @WithSettings
has higher precedence than the properties file, the generated number x
will be within the 100..999 range.
Finally, we will override settings by passing an instance via the API:
Configuration provided using withSettings(Settings)
method has higher precedence than configuration from instancio.properties
and @WithSettings
. Therefore, in the above example x
will be in the 1000..9999 range.