Furore devdays2017 tdd-2-advanced
- 1. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7. Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com Test Driven Development II - Advanced Richard Ettema, AEGIS.net, Inc.
- 2. Presented by • Name: Richard Ettema • Position: • Lead Consultant, AEGIS.net, Inc. • FHIR® Certified Implementer • Background: • 34+ years IT industry experience • 14+ years leading HIT development/implementation efforts • 4+ years contributing to the HL7® FHIR® specification (focus on testing) • Sr. Architect / Lead Developer for the Touchstone Project • Author of the AEGIS WildFHIR public test server and client
- 3. Test Driven Development with FHIR Intro Session Review • To ensure interoperability between applications claiming conformance to the specification, a testing framework has been established within the FHIR specification itself https://www.hl7.org/fhir/STU3/testing.html • This framework defines a Test Engine for processing a TestScript resource as a natural language, computable format of a test case • The TestScript resource is an implementation-agnostic description of tests that allows test engines to evaluate if a FHIR implementation conforms with the FHIR specification https://www.hl7.org/fhir/STU3/testscript.html
- 4. • Testing workflow example • How can we trust that the correction is being tested in the same way? Can we trust either test outcome? Known data facilitates known, expected outcomes We will review and examine how to ensure “Reliable and Repeatable Testing” during the Hands-on Exercises using a “Two Users, Same Data” scenario Test Passes Run Test Again Developer Correction Test FailsRun Test Reliable and Repeatable Testing
- 5. Identifying Your Testing Criteria; a.k.a. Asserts • Testing simple values • Is this the patient I expected? • Is this the operation response I expected? • Did I get multiple matches when I expected one? • Testing specification conformance • Is this element required? • Is this code value correct? • Testing conditionality or constraints • Can this element be expressed more than one way and still be compliant? • Is this element is only required when another element is present?
- 6. Asserts can perform… • simple operations • standard assert operators are constrained to the following: equals | notEquals | in | notIn | greaterThan | lessThan | empty | notEmpty | contains | notContains | eval • specification allows for use of XPath or JSONPath expressions • complex evaluations • specification allows for rules to be defined within the assert • specification allows for use of FHIRPath* expressions *FHIRPath is supported within the TestScript resource and by the Touchstone test engine, but will not be a focus of this session. To learn more about FHIRPath, see http://hl7.org/fhirpath
- 7. Complex Asserts • Are used when testing conditionality, constraints or simplifying an existing test construct • Support the use of FHIRPath • FHIRPath has expressions, functions, operations • Far more functionality than found in the simple assert operators • Built-in expressions such as dateTime and quantity • Expressions can contain operators • Functions like isDistinct, count, subsetOf, supersetOf • Support Rules and Rulesets (high level language scripted logic) • Touchstone Rules Engine supports Groovy, Schematron and XSLT
- 8. Complex Asserts - FHIRPath Example • FHIRPath provides a syntax neutral way to access the contents of a resource and can simplify assert logic constructs Assert condition: “Confirm that the searchset Bundle total number of entries is at least one (1).” • Let’s compare XPath and JSONPath to FHIRPath…
- 9. Complex Asserts - FHIRPath Example Comparison with XPath and JSONPath • XPath assert <assert> <operation value=“greaterThan” /> <path value=“/Bundle/total” /> <value value=“0” /> </assert> • JSONPath assert <assert> <operation value=“greaterThan” /> <path value=“.total” /> <value value=“0” /> </assert> • FHIRPath assert (equivalent logic) <assert> <expression value=“Bundle.total.toInteger() > 0” /> </assert> • FHIRPath assert (alternative logic) <assert> <expression value=“Bundle.entry.count() > 0” /> </assert>
- 10. Complex Asserts - Rules and Rulesets • The TestScript resource allows the use of Rules and Rulesets within the assert • Rules are called during TestScript execution • In Touchstone, the Rules are hosted within the Test Definition folders • Rules may be viewed and will be displayed in Test Results if selected • Rulesets are simply collections of one or more Rules • Allows for the definition of a group of Rules to be referenced within the TestScript in an efficient manner We will review and examine Rules and Rulesets during the Hands-on Exercises
- 11. FHIR Client or Peer-to-Peer Testing • TestScripts in Touchstone can be either Server-only, Client (Peer-to- Peer), or Multi-actor • Server-only: Touchstone initiates requests to the destination FHIR System and evaluates the response • Client (Peer-to-Peer): Touchstone waits for a request from the origin FHIR System to be received, evaluates the request, sends to the destination FHIR System, and evaluates the response • Multi-actor: Touchstone may act as the initiating system along with other FHIR Test Systems acting as either a Client or Server
- 12. Client (Peer-to-Peer) Testing - Test Setup • Select a Client TestScript from the Test Definitions list • Select and fill in any test data necessary for test execution • Origin Test System (Client) • Destination Test System (Server) • (Dynamic) Variables
- 13. Client (Peer-to-Peer) Testing - Test Execution
- 14. Client (Peer-to-Peer) Testing - TestScript Execution We will review and examine Client Testing during the Hands-on Exercises
- 15. Captured Message Exchanges • The Exchanges dashboard in Touchstone allows users to view all captured request and response messages • Touchstone will match an exchange with a test execution using these checks: • If your test server is already defined within Touchstone and is publicly accessible, the message can be matched by originating IP address • If that is not possible, the system attempts to use USER_KEY and ORG_KEY • Else, the system cannot match the message to a test execution
- 16. USER_KEY and ORG_KEY • USER_KEY and ORG_KEY are special placeholders • They can be sent by the client system as an HTTP request header or within the request payload • They identify the client system when the machine name or IP address would not
- 17. Introducing the Touchstone APIs • Test executions can be launched and monitored via remote RESTful web services • Provides the means to integrate Touchstone into your organization’s test executions for: • Internal automated regressions tests • Continuous Integration build processes • Documentation and example messages are available • Supported formats – JSON and XML
- 18. Touchstone API Capabilities • The Touchstone APIs allow for many of the same non-administrative functions as the User Interface • Test executions launched on behalf of a remote test user via Touchstone API will be visible to all members of your organization on the Touchstone UI • Any member of your organization can log in to the Touchstone UI and investigate test failures if needed
- 19. Touchstone API Services POST authenticate Authenticate with Touchstone; return new API session key POST testExecution Launch a new test execution for an existing Test Setup GET testExecution Return the status of a know test execution GET testExecDetail Return summary status of all test execution TestScripts GET scriptExecDetail Return test execution single TestScript details GET testReport Same as GET scriptExecDetail except returns FHIR TestReport
- 20. Touchstone API - Jenkins CI Server Integration Example • The Touchstone User Guide documents a Jenkins CI Server Integration Example • https://touchstone.aegis.net/touchstone/TouchstoneUserGuide, section ‘Touchstone API – Jenkins Integration Example’ • Illustrates the use of the Jenkins Groovy Plugin • Builds on the example code from the previous ‘Touchstone API – Definition’ section Due to not having a publicly available Jenkins CI Server at this event, there is no corresponding Hands-on Exercises for this topic.
- 21. Conformance Testing • Conformance Testing validates a system against known standards • FHIR Specification (including Implementation Guides) • Version support (forward/backward compatibility) • Continuous Conformance Testing shows that an organization is currently conformant, but also committed to remain conformant • Future development minded - interoperability needs to be addressed on a continuous basis • Development Aid - developers can integrate FHIR conformance testing into their build cycle to avoid costly conformance code rewrites later • Regression testing - validate that changes and enhancements are also conformant
- 23. Hands on Exercises • Reliable and Repeatable Testing - Two Users, Same Data • Complex Asserts • FHIRPath comparison to XPath and JSONPath • Rules and Rulesets • Advanced TestScripts • FHIR Client / Peer-to-Peer • Conformance Analytics Dashboard • Connectathon Test Track • We will continue our review of one of the test tracks for the next HL7 FHIR Connectathon 17 event and the development of TestScripts
- 24. Discussion (Q & A)
- 25. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7. Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com Thank you!