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 3.3.11, the available fixture types are:

• AD Add – Creates an object in an LDAP directory
• AD Delete – Deletes one or more objects
• AD Update – Updates one or more objects
• Load Fixture – Iterates over a list of data and replays nested fixtures multiple times with different data
• Lotus Add – Creates a document on a Lotus domino server
• Lotus Update – Updates a domino document
• Lotus Delete – Removes a domino document
• Password Set – Invokes the MIM password reset WMI
• Portal Add – Adds a record to the MIM Portal
• Portal Update – Updates one or more portal objects
• Portal Delete – Deletes one or more portal objects
• Portal Approval – Approves or rejects a pending portal request
• SQL Add – Inserts a SQL row
• SQL Backup/Restore – backups or restores an MS SQL database (useful for reseting test environments)
• SQL Delete – Removes a SQL row
• SQL Truncate – Empties a SQL table
• SQL Update – Updates a SQL Row
• Sync Disconnect – Makes an object a disconnector in MIM
• Sync Join – Connects a CS and MV object in MIM
• Sync Preview Commit – Executes a preview commit action against a CS object in MIM
• Sync Project – Projects a CS object as a particular MV object type
• Text File Delete – Removes a row from a delimited file
• Text File Upsert – Appends a row to a delimited file, or updates an existing row if it already exists
• Text File Erase – Removes all rows but the header row from a delimited file

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 3.3.11.

• AD Assertion – Check for the existence, non-existence, or attribute settings of an LDAP object
• CS Assert – Look up a connector space object and validate attribute values
• Load Assertion – Iterate over a list of data, and run child assertions with the values of the data rows
• Lotus Assertion – Find a domino server object and inspect and validate attribute properties
• Portal Assertion – Run a filter against the portal to check for existence or non-existence of objects, and  validate attribute values
• SQL Query – Run an arbitrary SQL query using connection settings of an SQL provider
• SQL Row – Select a specific row based on a key and assert against the values of columns
• Text File Assertion – Assert against the values in a given row of a delimited file
• Uplift Assertion – Create a simulated CS or MV record, and run unit test assertions of flow rule code

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.