This is an archive of the discontinued Mercurial Phabricator instance.

copies-rust: add a macro-based unit-testing framework
ClosedPublic

Authored by SimonSapin on Feb 25 2021, 5:42 AM.

Details

Summary

compare_values, merge_copies_dict, and CombineChangesetCopies
are APIs whose signatures involve non-trivial types.
Calling them directly in unit tests would involve a lot of verbose
setup code that obscures the meaningful parts of a given test case.

This adds a macro-based test-harness with pseudo-syntax to tersely
create arguments and expected return values in the correct types.

For now there is only one (not particularly meaningful) test case
per tested function, just to exercize the macros.

Diff Detail

Repository
rHG Mercurial
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

SimonSapin created this revision.Feb 25 2021, 5:42 AM
Alphare accepted this revision.Mar 2 2021, 9:18 AM
Alphare added a subscriber: Alphare.

This was a harder one, macro_rules!, for all their usefulness are not the easiest thing to digest.

It's a shame macro definitions cannot have docstrings. I guess your solution is simple enough. Are you planning to write the unit tests using this harness any time soon?

The plan is that @marmoute can write test cases using this harness at some point. I’m much less familiar with the *intended* behavior of various algorithms, so while I could write test cases by reverse-engineering the code I risk testing bugs without necessarily realizing they’re bugs.

We can have doc-comments on macro_rules! definitions, I felt that explaining usage was more useful near use sites.

The plan is that @marmoute can write test cases using this harness at some point. I’m much less familiar with the *intended* behavior of various algorithms, so while I could write test cases by reverse-engineering the code I risk testing bugs without necessarily realizing they’re bugs.

Makes sense.

We can have doc-comments on macro_rules! definitions, I felt that explaining usage was more useful near use sites.

Ah yes, I'm probably confusing this with adding a docstring to a macro call, not a definition.
I think I'd definitely prefer having the docstring on the macro_rules! definition, for sure. If you want to add a comment to point to the docstrings, that's fine.

This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.