pwhite704435

Using Lookups for Testing

Discussion created by pwhite704435 Employee on Oct 10, 2017
Latest reply on Oct 10, 2017 by pwhite704435

When I started off testing in Boomi, I took the same approach most others did - dump some data into a message shape, run it through the process and test the output.  Over time this started to get unwieldy, as my tests got more complex, and the number of attributes to test increased.  The business rule shape in particular led me to try the following approach.  

The advantages are:

  • Allows for specifying different sets of values for your attributes
  • Allows for testing both positive and negative scenarios (e.g. good data and bad data)
  • Reuse of test data throughout all your tests
  • Importing of test data from external sources (e.g. test scripts, spreadsheets etc)
  • Separates data from markup

The disadvantages:

  • Initial setup time is more than just dumping data into a message shape
  • It can be complex to get your head around initially - but if you're a QA geek (like me), you'll love it

 

Short Version

These are the main principles for seasoned Boomi Engineers

  • Export test data from your source of choice to CSV - it should have an Attribute (key) column, and multiple data (value) columns
  • Import this csv into a Lookup Table
  • In your process, use a set properties shape (DPP), with the property name being Test-AttributeName, and the value being a lookup of the attribute in the data column of choice
  • Create a message shape with the markup, add the Test-Attribute DPPs, and insert into the corresponding positions in the markup
  • Add the Test-Attribute DPPs to Business Rules as the Expected value (use the Function input), and the fields from the Profile as the Actual value

Long Version

 

Define your test data

  1. Starting off with a simple sheet like this.  DPP should be a formula like =CONCAT("Test-", A2) (more on that later).  
  2. Export it to CSV

 

Import your test data

Pretty simple:

  1. Create a new Cross Reference Table
  2. Import from CSV, check all the fields (you'll probably do this a few times as you update your test data)
  3. Select your CSV and import, resulting in:

Assign Test Data to DPPs

This is where things get a little long in the tooth, but the initial investment in time will pay off! It will help to have your test data spreadsheet open in another window, as there's a lot of copying and pasting.

  1. In your test process, first we want to assign the values to Dynamic Process Properties.  I've chosen the Test- prefix (above) to avoid clashing with other DPPs that may already be set within any processes you're testing.  
  2. Add a Set Properties shape, property type of Dynamic Process Property, and set the first Test-Attribute name (in this case Test-AccountNumber)
  3. In the Parameters column, click +
  4. Select your Type of Cross Reference Lookup, select your Test Data lookup, and select the Output Parameter of the value set you want to test 
  5. In the Input Parameters click +, select Input of Attribute (this is the first column in your test data csv), and enter a Static Value of the first attribute you're testing (again, AccountNumber)
  6. Repeat this for your other attributes

 

 

Create your Test Message

aka, merge data with markup

  1. Create a new Message Shape, and paste in your JSON/XML/DB markup (whichever one you're testing), stripped of values:
  2. For each Test-Attribute you've assigned, add a Variable
  3. Now add your variables into the Markup (just the json example here, you get the gist - but watch out for those single quotes!)
  4. Ok, that's the most painful part of the process done, now the benefits start

Using other value sets

So, if you're like me, one test is never enough, and I want to test other edge cases, invalid data, etc

  1. Copy your initial Set Properties shape
  2. Configure it
  3. Select your first Property (Test-AccountNumber again)
  4. Double click the Cross Reference in Parameters
  5. Select Valid 2
  6. Repeat for the other Test-Attributes

Much easier that time wasn't it

 

Setup the Business Rules

So now you should have a process that looks roughly like this (some steps ommitted). "Process to Test" can also be a component like a Map - this approach has saved me a lot of time in the past with both setting up Maps, and picking up regressions.

  1. Go ahead and add a Business Rule shape after Process to Test. I'm sticking with JSON from now on (it is the easiest after all)
  2. Setup your first Business Rule - first.add a Function type input, category Properties, Get Dynamic Process Property
  3. Enter the alias of Test-AccountNumber and Property Name of Test-AccountNumber (we're back to copy and paste land here)
  4. Now add a Field type input, pointing to AccountNumber
  5. Let's add our condition - we want it to be the Test-Attribute = Value, e.g. Test-AccountNumber = Account Number
  6. In Error Message, Insert both Values and configure your error message.  Mine is always the same, allowing for more copying and pasting:
  7. Now, see the really cool thing here? No more hard coding / repeated manual typing of expected values! Like I said, I really dislike that part about Business Rules, and I've gotten rid of the need.

Tying it all together

So, finally we should have a process that roughly looks like this

Obviously, this is a very simple example, and my real world scenarios use this to much greater effect.  e.g. I'll copy and paste that same Set Properties / Message shape into various tests, thus reusing again and again the Lookup data, rather than forgetting which message shape has what values.

Yes, initially this can be a bit cumbersome to setup, but once done, the benefits are clear.

Outcomes