Introduction

What is an Assertion? Is a query to validate a condition. It the query and the condition are the same, the Assertion is passed.  If they do not give the same value, the Assertion has failed.

This is where are tests validate that the fixture and schedule have acted in the way expected.

Assertions tend to be run at the end of a sequence of steps, to prove that the correct outcome has occurred, but they can also be run at the start to avoid false positives.

For example, we are testing that a user is created in AD.  When the test was previously run, if the account was not deleted, when we run the test again, the assertion will pass at the end, as the object was already present.  If we had a negative assertion at the start, to validate that the object is not present, this assertion would fail in the above example, and highlight that the test needs to be looked at in more detail.

Creating Assertions

There is three ways of creating Assertions in Identity Panel.  Similar to fixtures, they can be created inline within a test or using Time Traveller, as a separate assertion within Test Panel, or duplicated and tweaked from an existing assertion.

Assertion Creation - Inline

This approach allows the Assertion to be created within the test. If the fixture is also created inline, the benefit of this approach is that all the configuration can be viewed from a single place. This disadvantage of this approach is that the assertion can not be re-used.

Assertion Creation - From Scratch

This approach allows the assertion to be created from within Test Panel. It requires all the attributes and values to be manually entered. There is normally less attributes compared to when creating a fixture.

Step	Image
Log in to Identity Panel
Select Settings, and Test Panel
Select Assertions, and change the provider to the Test Provider (This is normally called Test or Testing)
There are several different types of Assertions available, in this scenario, we are creating an AD Assertion. Select AD Assertion and click New
Enter a Name, and Select AD Provider. For the name, the following format is recommend: {Object Type} - {System} - {What is being tested} ({DN Link}) Object Type - What type of object is it.  Is it an employee, contractor, group. System - The System that the assertion is going to be testing in.  AD, LDAP, SQL. What is being tested - This provides a short description of what is being tested.  It could be Is Present, or Is Not Present. It could be Account Details Set, or Full Attribute Test. DN Link - This is where the DN that is being used for the test is put. If the DN is hard coded, you would put the DN value in here.  If it is a Memo, you could include the memo name. For example: Employee - AD - Account Name (DN:123456)
Click the arrow, to view more details
We need to specify how to find the object we want to validate.  With Active Directory, this can be a DN or a LDAP Search. In this example, we will use LDAP Search, and enter the value: (&(objectclass=user)(employeeID=123456))
If we wanted to test that the object is not present, we can tick the Not Exists checkbox. This will cause the Assertion to fail if the object is present.
In this example, we want to validate the account name is correct. To do this, click the New Button under Attributes.
The Name is the attribute in AD The Value is the attribute we want it to match (Please not this is case sensitive)
Click the save button on the top toolbar, to save the assertion.  It can now be used in a test.

Assertion Creation - Copy existing Assertion

This approach can be the quickest way of creating Assertions, but it requires an existing assertion to be present.  Once the assertion is copied, it will need to be modified to support the scenario.