vRealize Suite Lifecycle Manager (vRSLCM) has its roots embedded firmly with CodeStream and the DevOps for IT management pack that is now no longer supported. Moving code/content between platforms and managing content were several of the main purposes of CodeStream and whilst vRSLCM does a number of other things, it still has a content management engine within it to perform content management tasks.

Unit testing is one of those tasks and is often something that vRSLCM users overlook as being too hard or taking too much time to develop.  Well, it really isn’t that hard and doesn’t take a massive amount of time.

In this article I’m going to take a few minutes to put together a custom unit test configuration for a vRealize Automation blueprint.

Why Custom Unit Tests?

vRSLCM (and CodeStream for that matter) provide out of the box unit tests for varying content types that can be captured via the content management engine within either product.  The tests are very basic orchestration workflows and serve to provide tests such as “does the content exist” in respect to a particular endpoint.

In most customer scenarios that type of test just doesn’t cut it.  What customers want is to save time and money by automating certain types of testing so that resources don’t have to be tied up.  This includes functionality testing such as “does my content get created successfully”.

Our Use Case

In this example I have put together a basic blueprint within vRealize Automation to represent something that a customer might create, capture and manage with vRSLCM.  It’s got a VM and an on-demand routed NSX-T network.

As a developer expands this blueprint and adds functionality it will need to be tested to make sure all the components are building and no errors are being encountered.  This is something that we can create a custom unit test for and hand over to vRSLCM.

Where Are The Unit Tests?

The link between CodeStream and vRSLCM has always been evident however as vRSLCM has developed those ties are gradually starting to be broken.  One of the big differences we have now is that with the latest GA version (2.1 at the time of writing) there is no longer an embedded vRO instance within vRSLCM.

In older versions of vRSLCM and CodeStream the unit testing workflows were held within this embedded orchestration engine and optionally deployed to specific external vRO instances if required.  With the latest version of vRSLCM this optional configuration is now mandatory.  Unit testing has to be performed using an external vRO instance, whether that be vRO within a vRA endpoint or a dedicated vRO appliance.

In this use case I am using an external vRO appliance that has been added as a capture and testing endpoint within vRSLCM.

Every content type has its own folder and common set of unit tests within.  These folders and workflows are deployed automatically to the vRO endpoint when it is added to vRSLCM as a test endpoint.

A Simple Unit Test

This example unit test is going to be basic but will show how unit tests can be put together.  The unit test will verify the content we are testing exists and then ask vRA to build something using it.  If the request to build something from the content suceeds then the unit test will pass, otherwise the unit test will fail.

Any testing workflows that you place into the common folder of a particular content type will be run for all content of the specified type.  If I create a unit test workflow called ABC and place it into the common folder within “Automation-CompositeBlueprint” then ABC will run for every vRA blueprint we choose to test with vRSLCM.

Here you can see my unit test workflow which performs the follow functions:

• Adds a vRA test endpoint to the vRO unit test server (so we can do things programmatically against our test vRA endpoint)
• Find the catalog item that matches the content we are testing
• Assign the catalog item to a service (to make it visible to a user and requestable)
• Request the catalog item (providing any specific input if required)
• Wait for the request to either succeed, fail or timeout
• Clear up the vRO configuration

The workflow uses the same inputs as the out of the box unit test workflows and is placed into the common folder for the composite blueprint type so it will run for every testing request that leverages this unit test vRO instance.

That’s It Right?

Well unfortunately not.  If you leave everything alone for 30 minutes then you should be good to go however if you don’t and try to initiate a test of some captured composite blueprint content then you will likely encounter a unit test failure.  This is because vRSLCM only checks the unit test workflows it needs to run every 30 minutes.

To ensure you don’t hit an issue it is best if you force vRSLCM to look for workflows on the vRO unit test server.  The only way (excluding API) to do this is to go through the steps of capturing workflow content from the vRO unit test endpoint.  You don’t actually have to capture the content, just ask vRSLCM to refresh its inventory of workflows.

Our unit test workflow is on a vRO endpoint so vRealize Orchestrator should be selected.

 

Hitting the “Get Latest Content” button will execute an API call from vRSLCM to the vRO unit test server refreshing the cached list of content.

You will be able to verify if the refreshed list of workflows contains the custom unit test workflow by typing the unit test workflow name in the field provided.  At this point you can cancel the capture.

Testing the Test

To make sure the unit test works we need to test it (the irony eh).  To do this a blueprint needs to be captured into the content management engine and then the “Test” option selected for the content version that needs to be tested.

In my environment I have a dedicated test tenant so this is the one I have selected.  I also want to deploy the content as it currently doesn’t exist there, run unit tests and stop if any failures are encountered.  Additionally the correct vRO unit test server needs to be selected so that vRSLCM knows which set of unit tests to run and where to run them.

Once the test has started the execution will be shown in the content pipeline as shown below (note blue means running, green is good, red is bad).

The “Test Conent” stage will enter a running state and will continue running as long as the unit test workflows are running (I expect there is a timeout value set within the vRSLCM code but nothing that I have come across yet).

The workflows should be visible as running with the unit test vRO server as well.

Assuming the workflows finish without error, the pipeline execution is marked a success.

The vRA test tenant now shows a successful build from our blueprint that the vRSLCM test was initiated for.

There are many more things you could add such as automated cleanup after a successful test to ensure no resources are tied up.  Additionaly specific unit test workflows can be added for complex custom services that require specific inputs however these must be named the same as the content they are testing and must be at the same level as the common folder, not within it.

Hopefully this is enough to get you started on custom unit testing.