Fixtures and Assertions

MIM Test Fixtures are used to execute actions directly against Identity Systems. Assertions are used to read data and check results.

Fixtures and assertions execute inside a test case as a special case of a schedule step. A canonical test case loads fixtures to manipulate data, runs schedules to synchronize, then runs assertions to validate results.

They may be defined inline inside a test case, or they may be created standalone in a separate section and added to (possibly multiple) cases as references.

In order for a test case as a whole to pass, the fixtures inside is must complete successfully, and the assertions must all pass.

Fixtures

The term "fixture" is a standard term used within the world of automated software testing, as well as in software packages that support database migration, or automatic version control of database schema and basic data.

In MIM Test Fixtures execute individual actions within a test case. By definition fixtures are actions that create, mutate, or delete data. Fixtures are provider type specific and each provider defines a range of possible fixture types. The list available fixtures depends on the version of Identity Panel, what providers are installed, and whether custom providers have been implemented.

As of version 6.2.3, the available fixture types are:

One of the key features of Fixture implementations in Identity Panel is that wherever, possible fixture actions are idempotent. This means that running the same fixture multiple times will have the same result as running it once. For example, if you run the same Portal Add fixture three times, it will create an object, but on subsequent calls it will do a filter query and automatically switch to performing an update if the object already exists.

All fixtures have some shared common fields:

• Name – Identifies the fixture, must be unique if defined as a re-usable fixture
• System – The MIM Test provider to use for executing this fixture. The system provides both the connection settings the the actual implementation for how to interpret the fixture
• Notes – Optional comments related to fixture usage or definition
• Preferred Servers – Optionally specify server(s) to restrict execution of the fixture to
• Memos – Allows saving of pre-calculated values that may be re-used in this and other fixtures.

In addition to common fields, fixtures have settings specific to and implemented by the provider. For example, many types of fixture have an Attributes list, and a key field or DN.

Assertions

Just like "fixture", "assertion" is a term from the world of automated software testing. An assertion performs a validation of expected state. Assertions may run at the beginning, middle, or end of a test case, but for a case to pass all assertions in it must pass.

Typically the settings for assertions look very similar to fixtures because they have similar needs regarding connecting to external systems, querying for data, executing on particular servers, etc. The primary difference is that assertions are readonly, and merely check for expected states.

An assertion essentially makes a statement of expectation, and if the environment does not conform to the expectation the assertion fails. Depending on the nature of the assertion, this may be something like an account not existing, a failure of login connectivity, or even something as simple as an attribute that wasn't updated to the expected value.

Like fixtures, assertions are associated to providers and different providers offer different types of validation action. The following assertion types are included with version 6.2.3:

Assertions have the same common fields as Fixtures:

• Name
• Notes
• Preferred Servers
• Memos

In addition assertions that look up an object, such as an AD or Portal assertion often have a Result Memos property. This is a separate section for memos that execute in the context of the object found by the assertion. They can be used to cache values for use later in the test case. For example, if a field like an account name or workforce ID isn't known until execution time, it can be discovered by an assertion an remembered for later use in fixtures, or even other test cases in the suite.