Skip to content
This repository has been archived by the owner on Apr 18, 2024. It is now read-only.
andrequina edited this page Dec 16, 2014 · 6 revisions

Codes below (e.g. CR01) reference Sprinkler test IDs.

Baseline Testing

Conformance Testing

  • does the server support all the resources and operations that it claims?
  • does the server support any resources or operations that are not advertised?
  • does the server support any non-standard resources or operations?
  • does the server implement any profiles?
  • [C001,C002]

Resource Testing

  • create [BI01,CR01,CR02,CR03,CR04,CT05]
  • update [BI02,UP01,UP02]
  • read [BI02,R001,R002,R003,R004]
  • read (type) [BU02]
  • delete [BI03,DE01,DE02]
  • validate [V001,V002,V003,V004]

History Testing

  • vread [HI03]
  • history [HI01,HI02,HI03,HI04,HI05,HI06,HI07,HI08,HI09,HI10,HI11]

Search Testing

Test the extent of the search capabilities supported.

  • no criteria [SE01]
  • non-existing resource [SE02]
  • id
  • parameters [SE03,SE04,SE24,SE25]
  • parameter modifiers (:missing, :exact, :text, :[type]) [SE23]
  • numbers (= < <= > >= significant-digits) [SE21,SE22]
  • date (all of the permutations?)
  • token
  • quantities [SE21,SE22]
  • references [SE05]
  • chained parameters
  • composite parameters
  • text search logical operators
  • tags [TA08], profile, security label
  • _filter parameter
  • result relevance
  • result sorting (_sort parameter)
  • result paging
  • _include parameter [SE06]
  • _summary parameter
  • result server conformance (report params actually used)
  • advanced searching with "Query" or _query param

Profile Testing

  • Create resource that uses profile
  • Create base resource that does not use the profile
  • Post resource with unsupported profile data and verify (TBD, per spec)
  • TBD

Use Case Testing

The FHIR spec lists three common use-cases and the required capabilities for each.

Format Testing

  • xml support [CT01,CT02]
  • json support [CT03,CT04]
  • xml & json equality

Messaging/Mailbox Testing

  • TBD [MA01,MA02,MA03]

Transaction Testing

  • Bundles [BU01, BU03, BU04]
  • Transaction: Add [TR01]
  • Transaction: Update [TR02,TR03]
  • Transaction: Delete [TR04]

Tags

  • create [TA01]
  • read [TA02,TA04,TA05,TA06]
  • update [TA03,TA09,TA10]
  • delete [TA11,TA12]
  • history [TA07]
  • search [TA08]

Questionnaires

  • Download completed questionnaire [QU01]
  • Reupload as template [QU02]
  • Download template [QU03]
  • Upload new questionnaire [QU04]

Signatures

  • Posting feeds with valid signature [DS01]
  • Posting feeds with invalid signature [DS02]

Compatibility Testing

  • Compare resource overlap
  • server sA supports resources r0, r1, r2
  • server sB supports resources r1, r2, r3
  • profile compatibility on overlapping resources
  • does sA profile/restrict r1 in a non-compatible way from the perspective of sB?
  • extension compatibility on overlapping resources
  • do sA and sB support the same extensions?
  • if not, is there data loss or corruption when data is exchanged?
  • operation compatibility on overlapping resources
  • for example, sA supports READ and UPDATE only while sB supports full CRUD
  • does sA profile/restrict UPDATE to only fields f1, and f2?
  • what happens if sB updates a local copy (with a full transaction that includes field f3) and then tries to update the same resource on sA?
  • performance of client reference implementations on executing those operations on overlapping resources across systems
  • does it work? was there data loss? data corruption?
  • of the “pipes” or “pathways to interoperability” between sA and sB, which are actually interoperable?
  • Can server sA validate a resource from server sB using a profile living on sB?
  • Cross server references?
  • Bulk transfers/transactions — can you POST a bundle or composition??

Stability Testing

  • Add large amounts of whitespace to XML
  • Re-order resource JSON
  • Load large numbers of resources
  • Add long data fields
  • Post large resource with large narrative
  • Add unsafe HTML to narrative
  • Provide partial dates/times and validate precision
  • Provide doubles and verify the precision is maintained
  • Send time data in multiple timezones and validate