It’s always fun when we can eat our own dog food, er, drink our own champagne. Some of us sales and marketing people recently discovered that our QA team had been performing integration testing of InRule using InRule. That’s no typo. Needless to say, we were excited to share the story…
First, a little background. The new functionality in the InRule v4.6 release is all about REST services. Specifically, customers have repeatedly expressed interest in three use cases:
- Pull data from REST-based services at runtime. InRule has supported retrieving data from databases, SOAP services, .NET methods, etc. for quite some time. InRule v4.6 now provides the ability to call REST services to retrieve data.
- Execute rules via a REST service call. There has been a SOAP endpoint on the irServer rule execution service for years which works well for calls from the back-end written in .NET or Java. Increasingly customers have asked to call that service from the front-end with languages like JavaScript, so there is a new REST endpoint that makes it possible out of the box.
- Have one rule application call another rule application. For reasons beyond the scope of this post, customers frequently want to slice large rule applications into smaller pieces and then have one rule application make calls to the others. By combining the ability to call REST services and exposing the rule engine via a REST endpoint, this can now be done out of the box with no programming required.
While building this functionality, the engineering team wrote many unit tests that run on every build. But like all good software companies we like a nice set of integration tests to uncover more complex issues. Since this new release included functionality for both calling and hosting REST services, one of our top QA people, Dave Hreczany, saw an opportunity to use some parts of InRule to test other parts of InRule. He puts it best when he says:
…it seemed like a natural fit to use irAuthor, which is a user friendly interface. You’ve got the mouse, you’ve got the keyboard, you really don’t need a lot of programming background to use irAuthor.
He started out by setting up irAuthor calls to REST endpoints in Azure, Jenkins, Dynamics CRM and others. He then used irVerify to execute the calls and make sure the rule engine pulled in the appropriate data at runtime. This meant he did not have to spend any time in Visual Studio creating sample services, test harnesses and so forth. When the newly developed functionality did not work at as expected he had rule tracing to help diagnose the issue. Since we use an Agile approach to develop InRule, issues were easy to resolve long before they were ever released.
Once we were confident that the ability to call REST services was complete, the team moved on to adding a REST endpoint to the rule execution service. It was at this point Dave realized he could use that newly completed functionality to test the execution service’s REST endpoint. This had the additional benefit of confirming customers would also be able to have one rule application call another out of the box. And as with the earlier tests, Dave was able to save even more time since he didn’t have to create a test harness because irVerify served that purpose:
Troubleshooting – there’s a big time saver there. You only had to troubleshoot what you were testing, you didn’t have to troubleshoot my test code, and then troubleshoot the test error, and then what was sent over the wire. And we didn’t have to open up any third party tools to sniff the wire to see what the actual request and response was. All of that was done within irVerify and rule trace.
In the end, Dave was very satisfied with the results of using InRule as a testing platform. What started out as a simple approach to use InRule to test one bit of functionality turned into an extremely robust testing framework that we will use for future projects:
What happened at the end was we have one rule app that is able to exercise InRule, irSOA, HTTP, various operations and for the two formats we support, XML and JSON. Any functionality we come up with can be tested with this, I call it the “rule executor rule app” – which is basically InRule calling InRule calling another rule app. So, InRule calling irSOA which calls a rule app which calls a REST service.
Kudos to Dave for his creativity in using InRule in a very unique way! If your use of InRule is out of the ordinary, we would love to hear about it in the comments below.
