Skip to content

principles

Jump to bottom
Bell, Glenn S edited this page Feb 15, 2022 · 1 revision

Principles for writing test code

Versioning

  • Protocol test cases: double-check for spec compliance
  • Functional test cases: add spec number to test description/header
  • For functional test cases, note the version of the spec you used in the test description (header). If you update a test case, update the spec version as well.
    • Before we finalize the code, we will double-check all test cases based on older versions of the spec for compliance.

Development Guidance

  • Whenever possible, we will follow the test steps exactly as they are written in the test spec.
This is most critical for the verification steps. This will allow the third-party testing agency which is verifying
our code to quickly see that it matches the doc.
  • We will use the following interpretations of the test spec (some -- maybe even all -- of which are explicitly stated in the test spec but are collected here for clarity):
    • If not otherwise specified, the FCC ID and user ID corresponding to CBSDs used in a test case are to be whitelisted before the registration of the CBSD.
    • If not otherwise specified, the SAS UUT is notified about any and all SAS Test Harnesses and they become part of its peer group.
    • If not otherwise specified, “inject a PPA” or “inject PPA Information” refers to the injection of the PAL DB record and subsequently the zone (+cluster list, PAL IDs) itself.
  • We will re-use test data as much as possible.
  • Details
    • Location for reference model code: harness/reference_models/{$folder_name}
  • We’ll use domain proxy certs for most test cases to preserve configurability (except in those cases where specific certs are needed).
Clone this wiki locally