After reading this blog, you will have the knowledge to be able to set up and run your own rule extension unit tests. This will help you develop solutions quicker, and do so to a higher quality. In the last blog in this identity management testing series, we looked at some of the issues with writing code and testing it with the MIM sync engine.
In summary, the main issues were:
- Debugging: blocks other users
- Time-consuming: needs to be run in the sync engine
- No automation: unable to see performance
- Required a connection to the sync engine server
It was a combination of the above issues that led me to look for a better approach to testing sync engine rule extensions.
In a project I’ve been recently involved in with a customer, unit tests have allowed me to test code much quicker. I’ve been able to identify parts of the code that were taking too long to run, and managed to reduce the time one of the rule extensions took to run from 400-500ms to under 50ms.
Here, I’m going to demonstrate how you too can see the benefits of testing code using this particular method.
For this demo, I have set up a Visual Studio Team Services project. On the sync server, I have installed Visual Studio 2017, and set up a solution. This solution has three folders in it: one for the rule extensions, one for the unit tests, and another which stores the DIIs. I have created an empty rule extension project in the ‘Project’ folder.
Create a unit test for the rule extension
To create the unit test, select the method you want to test. Then, right-click and select ‘Create Unit Test’. Before you start writing any tests, you need to create the Attributes, CSEntry and MVEntry objects that will be used for the tests.
First, create the attributes (Attrib) that will have values stored in them. These can be created using the code below:
You then repeat this for all the attributes we want to set values on. If you want to test what happens when the attribute is not present, set the return value to false.
Create CSEntry object
Next, create the CSEntry object. Create a private CSEntry attribute, then create the public SAPUserRuleExtensionsTest(), which will be where the CSEntry and MVEntry get declared.
Use the code below to create the CSEntry object, which has two attributes: “BAPI_USER_GETLIST_BAPIUSNAME_FIRSTNAME(Firstname)” and “BAPI_USER_GETLIST_BAPIUSNAME_LASTNAME(Lastname)”. Any other attribute name will return the defaultAttrib, which has IsPresent set to false.
Repeat this for the MVEntry object.
Write the test cases
Once this is complete, you will be ready to write your test cases. These are made up of the first part, which is setting the values:
Once the values are set, we create the rule extension object, initialise and terminate methods, as – even though the rule extension might not use them – if something breaks, or does not work correctly, it will cause the rule extension to fail.
After doing this, set the expected result. This is done using a conditional parameter, which you will have to configure. The actual result is also set, based on what should have been updated in the MVEntry object.
Then, compare the two values, to see if they are equal, and – if they are – your test has passed.
Run the tests
You are now ready to run the tests, confirm that they are failing as expected, and write the rule extension code.
Once the code has been written, Visual Studio will detect that you have some tests to run against this method. You can run tests by clicking on the passing, and then selecting ‘Run All’. You will now have two tests, both passing. One is taking five seconds to run, the other is taking 26ms.
To investigate why one of the tests is running so slowly, you can right-click on the test, then select ‘Debug Selected Test’. Remember to add some breakpoints first. You can now step through the code, as if the sync engine was running this.
It could be reading a config file that is causing a delay, or an SQL Query that is not very quick. The idea is that you can spot a path in the code that is slower than tests, and fix the issue. You can now refactor the code, and then run the test again. To do this, right-click the test, and select ‘Run Selected Test’.
The test will now have completed, and you should be able to see it running a lot quicker. I like to think it all adds up; if there were 200 changes in the connector space that call this method, it would have taken 1000 seconds. Even managing to reduce that by half, you would knock 500 seconds off the sync cycle time. Even reducing it by 1 second, you would still reduce a sync cycle by 3 minutes.
So, now you know how to set up unit tests to test rule extensions written for the sync engine.
To summarise, the advantages of this approach are:
- Development can take place anywhere, even without a network connection to the MIM server
- You are no longer limited to two consultants working on the solution at once (you could pay for more concurrent server licenses to get around this)
- Testing and debugging code no longer blocks other consultants working
- Compiling code no longer stops sync cycles running
- Performance of the code can be monitored, and issues identified and resolved more easily
- Tests can be run quicker, with a wider range of values. You can quickly respond to queries from a user on what would happen if certain values were flowed in
- Conditional parameters allow testing of production values, as well as test or dev
If you have a different approach to testing your code, please share it with me. You can contact me directly via email – firstname.lastname@example.org.
Learn more about the Microsoft technologies making identity and access management easier than ever and how to securely enable a more productive workforce by viewing a recording of our webinar: Navigating the world of identity and access management.