Several of the template classes have a verify() method for lightly testing custom child classes. For example, LifterTemplate.verify() checks that lift() and unlift() are inverses and does a finite difference check for lift_ddts() (when implemented). Most of the verify() methods raise a VerificationError at the first sign of trouble, but this isn't uniform. The purpose is of verify() is to give the user concise info on what appears to be working and what appears to not be working.
Proposed verification protocol:
- Do as many tests as possible, even if one test "fails"
- Print the results of all tests at the end
- Then, raise a
VerificationError if any tests have failed
- Unit tests of
verify() don't need to get out of hand to get total line coverage, but verify() may be used to implement certain unit tests.
When all verify() methods are standardized, it should be straightforward to implement verify() for the ROM class.
Several of the template classes have a
verify()method for lightly testing custom child classes. For example,LifterTemplate.verify()checks thatlift()andunlift()are inverses and does a finite difference check forlift_ddts()(when implemented). Most of theverify()methods raise aVerificationErrorat the first sign of trouble, but this isn't uniform. The purpose is ofverify()is to give the user concise info on what appears to be working and what appears to not be working.Proposed verification protocol:
VerificationErrorif any tests have failedverify()don't need to get out of hand to get total line coverage, butverify()may be used to implement certain unit tests.When all
verify()methods are standardized, it should be straightforward to implementverify()for theROMclass.