This structure still uses the QUnit test harness but takes better
advantage of TypeScript improvements that require the use of classes.
Notably, this also allows us to have instance state on our tests and
methods that use that instance state.
In this commit, I moved the env module-global variable into the
ValidationTest superclass, which then allowed me to create a
validate method that uses this.env.
In practice, we expect that an Ember wrapper for this library would
create an API (either exported functions or an exported object) that
constructed the Ember environment and exposed validation function that
used that environment. As a reminder, at the moment, the environment
encapsulates the Ember.get vs. pure [] distinction as well as the
validation registration mechanism (which, in Ember, would be via the
resolver/container).
The benefit of this structure is that we could write validators once
that are agnostic to these concerns and use them both inside of Ember
(with Ember objects) and outside of Ember (with pure POJOs and no Ember
runtime present). In an ideal world, we could even get non-Ember users
to help maintain the validators.
This structure still uses the QUnit test harness but takes better advantage of TypeScript improvements that require the use of classes.
Notably, this also allows us to have instance state on our tests and methods that use that instance state.
In this commit, I moved the
envmodule-global variable into theValidationTestsuperclass, which then allowed me to create avalidatemethod that usesthis.env.In practice, we expect that an Ember wrapper for this library would create an API (either exported functions or an exported object) that constructed the Ember environment and exposed validation function that used that environment. As a reminder, at the moment, the environment encapsulates the
Ember.getvs. pure[]distinction as well as the validation registration mechanism (which, in Ember, would be via the resolver/container).The benefit of this structure is that we could write validators once that are agnostic to these concerns and use them both inside of Ember (with Ember objects) and outside of Ember (with pure POJOs and no Ember runtime present). In an ideal world, we could even get non-Ember users to help maintain the validators.