Writing Test Blueprints

What is a test blueprint?

• A test blueprint is a YAML catalog item that can be deployed to a given location
• It should deploy the entity under test and make assertions that it behaves as expected
• It is normal to use the Test Case Entities for this

Example Test Blueprint

Below is a simple example (with a small number of assertions to demonstrate the principle):

brooklyn.catalog:
  items:
  - id: simple-app-test
    version: 1.0
    itemType: template
    name: Simple app test
    item:
      services:
       - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
         id: targetapp
         brooklyn.config:
           wars.root: https://tomcat.apache.org/tomcat-8.0-doc/appdev/sample/sample.war
       - type: org.apache.brooklyn.test.framework.TestCase
         name: "Effector Restart, Stop & Restart Tests"
         brooklyn.config:
           targetId: targetapp
         brooklyn.children:
         - type: org.apache.brooklyn.test.framework.TestSensor
           sensor: service.isUp
           timeout: 20m
           assert:
           - equals: true
         - type: org.apache.brooklyn.test.framework.TestHttpCall
           name: Check Servlet HTTP Response Status Code
           url:
             $brooklyn:formatString:
             - "http://%s:%s/hello"
             - $brooklyn:component("targetapp").attributeWhenReady("host.address")
             - $brooklyn:component("targetapp").attributeWhenReady("http.port")
           applyAssertionTo: status
           assert:
           - isEqualTo: 200

More Advanced Test Cases

Test cases can cover a wide range of scenarios beyond just initial deployment. For example:

• They can test that effectors have the desired effect
  • For example, stopping/restarting the process, deploying a WAR, or resizing a cluster
• They can test recovery policies
  • For example, killing the process to confirm that the auto-restart policy kicks in
• They can test auto-scaling policies
  • For example, using a load-generator to apply load to the system, and confirming that the cluster scales up and down accordingly

Any behaviour encoded in the blueprint should be testable.

Formal Contract For a Test Blueprint

Below is a more formal description of what is expected of a test blueprint.

A blueprint that uses the stock test-case entities will get this for free!

A test blueprint should:

• Start the entity under test and make assertions against it in the start effector
• If the test passes, the app’s startup should succeed (i.e. report itself as service.isUp=true and service.state=RUNNING)
• If the test fails then the blueprint should set its sensor service.state=ON_FIRE
• Tear down all resources that were used by the test in the stop effector