vRealize Code Stream Management Pack for IT DevOps (code named Houdini by VMware) allows us to treat our vRealize Automation Blueprints, or other objects, as pieces of code that can be promoted between environments. In previous posts we’ve done just this, but a glaring piece was missing in during those articles. Promoting code between environments is great, but we’ve got to test it first or this process is only good for moving code around. A full release pipeline including unit tests can make your environment much more useful for organizations trying to ensure consistency.

Houdini Unit Testing

The first thing that has to be done is to add a testing endpoint if not done already. The steps for creating endpoints can be found in a previous post on Houdini endpoints. Once this is done, we can start by writing up some unit tests in vRealize Orchestrator. The types of tests you’ll be running will depend on the type of blueprints, and the functions they provide. For the purposes of this post, we’ll be working with an XaaS Blueprint that snapshots a VM. We’ll write a new unit test that requests the XaaS Blueprint in our testing endpoint.

Here’s what you need to know before you write your unit tests in vRO. Each of the package types that can be tested have their own folder under “Content Management Tasks” that were created when you import the Houdini package during installation. There is a common folder under each of those package types. Anything in the common folder will be run during the testing phase. By default, there is a workflow created that checks to make sure that a blueprint was created and exists in the testing endpoint. You can create additional workflows if you’d like and place them in this common folder to be run during the testing phase. As you can see from the screenshot, I’ve created an additional workflow named “theITHollow-Request ASD Blueprint”. Now when a test is run, each of the two blueprints in the common folder will be run.

Now let’s request another package and test it. Go to the Houdini catalog and request a “Single Package Request” and run it through our testing framework.

Under the Actions tab select at least the capture content and deploy to test actions. You could also release to production if you feel like it but we only need to demonstrate the testing during this post.

Select the package type, source endpoint and the specific package you want to test.

On the “Test Details” tab, select the testing endpoint.

Enter a version comment and then submit the request.

As the package is requested we can switch over to the code stream tab to view the pipeline execution. You can see that our deployment was successful.

If we drill into the “Test Content” task we can see the details about the tests. You can see the package name, type etc.

If we have look at the “Raw Input Properties” we can see the JSON data that is used as inputs for the unit tests.

[
  {
    "name": "workflowId",
    "type": "String",
    "value": "ae3cfd13-0dd9-4046-bdb0-d33b2a2d4f6e"
  },
  {
    "name": "workflowName",
    "type": "String",
    "value": "RP Test Content Remote"
  },
  {
    "name": "properties",
    "type": "JSON[]",
    "value": [
      {
        "type": "string",
        "name": "packageVersionLink",
        "value": "/houdini/package-versions/80915bbf-243d-4282-92a3-945ec647a438"
      },
      {
        "type": "string",
        "name": "clmRequestId",
        "value": "745be98d-1b9a-4121-b23a-c564a04c647c"
      },
      {
        "type": "string",
        "name": "requestId",
        "value": "2766389f-cb55-4257-8073-38e64c9059ef"
      },
      {
        "type": "string",
        "name": "unitTestConfig",
        "value": "Default"
      },
      {
        "type": "string",
        "name": "packageId",
        "value": "1927fb4c-6ae9-4c0b-b807-bcf3edc22ccd"
      },
      {
        "type": "string",
        "name": "packageName",
        "value": "ES_Create a snapshot"
      },
      {
        "type": "string",
        "name": "testContentEndpoints",
        "value": "houdinitests"
      },
      {
        "type": "string",
        "name": "branch",
        "value": "master"
      },
      {
        "type": "string",
        "name": "packageType",
        "value": "Automation-XaaSBlueprint"
      },
      {
        "type": "string",
        "name": "version",
        "value": "2"
      }
    ]
  }
]

Lastly, if we look at our workflows in vRO we can see how the testing turned out and which workflows were executed during our deployment. Notice that all of the workflows in the common folder were executed. Also, take a look at the two other workflows in the parent folder. The one named “ES_Create a snapshot – Test1” executed while the “Other Tests – Test1” did not. This is because any workflows in the parent folder that are named the same as the package will run during the testing phase. You may further use this hierarchy to augment your testing methodology.

Summary

A code pipeline is relatively worthless without some sort of test to ensure that the functionality is working after moving environment. Now that you understand how to use these unit tests, your code pipeline can really start working to your advantage. Good luck with your unit testing and code promotion.