Stream: implementers
Topic: TestScript.rule/ruleset?
Ivan Dubrov (Jan 30 2018 at 19:52):
I don't understand how TestScript.rule/ruleset is supposed to work. Which type of resource TestScript.rule(ruleset).resource should be pointing to?
Lloyd McKenzie (Jan 30 2018 at 20:51):
@Richard Ettema
Jason Walonoski (Jan 31 2018 at 16:18):
It doesn't link to a resource. It links to an external rule (as a function, program, code, whatever) that can be used in an assertion. This is the magical escape hatch when TestScript assertions as defined do not have enough functionality to test the scenario in question.
Ivan Dubrov (Jan 31 2018 at 17:05):
Ah, I see. I was hoping it would allow me to reuse block of asserts somehow (I guess, technically it does allow that, by using custom convention).
Richard Ettema (Feb 01 2018 at 15:06):
Yes. The rule and ruleset elements are defined to let the test engine implement an external rules engine. In the case of Touchstone we use this to provide the ability to define Groovy, XSLT or Schematron based asserts. Our online documentation describes this in detail in our Test Authoring Guide here https://touchstone.aegis.net/touchstone/testAuthoring.
Bas van den Heuvel (Feb 01 2018 at 15:13):
How would you specify a set of actions that are expected in in a certain order? Is this the purpose of the ExampleScenario resource?
Richard Ettema (Feb 01 2018 at 15:19):
The TestScript tests and operations are executed in sequential order. Overall, 'setup' then 'test(s)' then 'teardown'.
Richard Ettema (Feb 01 2018 at 15:23):
The ExampleScenario resource is draft and (very) recently added. I don't even see a Resource Proposal for it. So, not sure what the intent is (yet).
Lloyd McKenzie (Feb 01 2018 at 15:43):
The ExampleScenario is to help provide documentation in an implementation guide to highlight what a particular workflow might look like and what instances (and versions of them) would be involved. It's a very different usage from TestScript.
Bas van den Heuvel (Feb 01 2018 at 15:51):
So if one would want to specify an order of events on a FHIR repo in way that can be used in regression testing, how would you approach this?
An example scenario would be trigger some event, $apply a plan definition. interact with the CarePlan, update the CDR based on the results of the interaction... -
Lloyd McKenzie (Feb 01 2018 at 15:56):
Example scenario isn't intended to trigger anything - it's intended as documentation only
Lloyd McKenzie (Feb 01 2018 at 15:56):
It's for inclusion in an implementation guide as an explanation of "here's what a real-world usage situation might look like"
Richard Ettema (Feb 01 2018 at 17:03):
Sounds like there should be a relationship to TestScript; something like being able to generate a TestScript from an ExampleScenario. Just a thought.
Lloyd McKenzie (Feb 01 2018 at 17:22):
I'm not sure that would be terribly useful. The behaviors defined in the example scenario aren't "thow shalt" items. They're just "in this case, stuff worked out this way".
Ivan Dubrov (Feb 01 2018 at 19:53):
That link to authoring guide was incredibly helpful!
One thought I have is that, I think, there is a functional gap between external rules and completely "standard" TestScripts. Would be helpful to have a way to reuse simple assertions (like "check that response is ok + plus few other checks, like resource type") without resorting to external rules engine. Something really simple as having a block of assertions inside rule/ruleset definition + some semantics adjustment, like being able to reference ruleset/rule parameters in assertions as variables.
That would improve tests interoperability.
Richard Ettema (Feb 01 2018 at 20:04):
There is an existing gforge tracker to address this which is currently in a "Consider for Future Use" condition - https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9197&start=25.
I hope to get time to work on this in the near future. Not sure if I'll get it in in time for R4 ballot.
Last updated: Apr 12 2022 at 19:14 UTC
