Stream: TestScript Resource
Topic: Fully specified vs. Abstract TestScripts
Robert Scanlon (Apr 30 2021 at 17:09):
Right now, the expectation is that TestScripts are fully specified -- they contain all the information necessary for two independently written test execution engines to execute a set of test steps in the same way. That has some nice properties, but it presents a really high bar for anyone that wants to write tests for FHIR APIs -- either go the 'standardized' route and learn how to write TestScripts, or go their own way so they can leverage their existing tools and experience for testing RESTful APIs.
Robert Scanlon (Apr 30 2021 at 17:09):
I think it would be very useful to be able to represent the concept of TestScript a bit more abstractly, so if someone wants they can write a test using the tools of their choice, but present a common API for describing the test (even if it is just a name and description), executing the test (via an operation on /TestScript, like /TestScript/$execute), and reporting the results of the test (TestResult). That way you can either write tests as a 'fully specified' TestScript (which could be a profile on TestScript where 'test' has a min of >= 1, and that has a different set of expectations on what you can use it for), or provide your own testing software that provides a standardized FHIR API that can be easily integrated into multi-purpose FHIR testing systems.
Jose Costa Teixeira (Apr 30 2021 at 17:58):
We are looking at capturing what we (currently) call "acceptance criteria"
Jose Costa Teixeira (Apr 30 2021 at 17:58):
This is not really a test description (or is it?)
Jose Costa Teixeira (Apr 30 2021 at 17:58):
It would take the form of somewhat structured narrative, like Gherkin
Last updated: Apr 12 2022 at 19:14 UTC
