Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a testing concept and infrastructure for different plugin groups, specifically schemas #19

Open
apirogov opened this issue Aug 23, 2022 · 1 comment
Labels
enhancement New feature or request prio:B
Milestone

Comments

@apirogov
Copy link
Collaborator

apirogov commented Aug 23, 2022

We check plugins superficially whether they look like they implement the required interface, but many properties can only be verified through testing.

We need some way how testing for different plugin types can be automated as much as possible, that means make the core do the heavy lifting and provide interfaces and helpers for plugin developers. Possibly, the plugin groups must be extended to support testing machinery and define tests.

for schemas specifically:

  • There is a set of inputs that should be accepted and is possibly normalized (so parsing maps unnormalized inputs to a subset of normalized valid inputs)
  • Make sure that resulting normalized inputs are loaded back as themselves
  • I.e. that a schema can load what it dumps and specifically, parse(dump(instance)) == instance (bijective on normalized data)
  • The exported json schema must accept a (non-strict) superset of inputs compared to the pydantic schema (more lenient)
  • The parent schema and minor revisions of a schema must also accept a superset of inputs (orthogonal to json schemas)

There should be helpers to check whether two schemas are compatible - this is useful both for parent/child schema tests and also for comparing a schema class with or without a modification (i.e. version-affecting change).

  • Schemas should have instances and non-instances attached that are automatically tested

Possibly looking at hypothesis would make sense for property-based checks.

In general, for schema plugins we should check using pytest (to complement the plugin loading checks):

  • check that instances validate against the exported json schema

  • some manual tests of parsing/instance construction for all expected situations and triggering different parsers etc

  • also automated tests with random instances, if possible

  • all of the above, but called for the parent schemas (check "parent compatibility")

  • Converting from and to partial schemas: from_partial(to_partial(instance)) == instance

  • associativity of partial updates?

@apirogov apirogov added enhancement New feature or request prio:B labels Aug 23, 2022
@apirogov apirogov added this to the v0.1.0 milestone Sep 5, 2022
@apirogov apirogov added prio:A and removed prio:B labels Sep 12, 2022
@apirogov
Copy link
Collaborator Author

apirogov commented Jan 2, 2023

Deprioritized until it is clear whether porting schemas to LinkML would make more sense (e.g. if it does these things correctly, or adding it there would make more sense)

@apirogov apirogov added prio:B and removed prio:A labels Jan 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request prio:B
Projects
None yet
Development

No branches or pull requests

1 participant