Export a registry of all integration tests #1449
Conversation
d0110b9 to
97b5f0a
Compare
| fn assert_placeholder_actor(exp_bal: TokenAmount, v: &dyn VM, addr: Address) { | ||
| let act = v.actor(&addr).unwrap(); | ||
| assert_eq!(EMPTY_ARR_CID, act.state); | ||
| assert_eq!(*PLACEHOLDER_ACTOR_CODE_ID, act.code); | ||
| assert_eq!(&Type::Placeholder, v.actor_manifest().get(&act.code).unwrap()); | ||
| assert_eq!(exp_bal, act.balance); | ||
| } | ||
|
|
||
| #[exported_test] | ||
| pub fn placeholder_deploy_test(v: &dyn VM) { | ||
| // Create a "fake" eam. | ||
| v.set_actor( | ||
| &EAM_ACTOR_ADDR, | ||
| new_actor(*EAM_ACTOR_CODE_ID, EMPTY_ARR_CID, 0, TokenAmount::zero(), None), | ||
| ); |
There was a problem hiding this comment.
This just changes some fragile assumptions here don't work on the FVM workbench
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #1449 +/- ##
==========================================
- Coverage 91.11% 90.99% -0.13%
==========================================
Files 146 147 +1
Lines 27936 27981 +45
==========================================
+ Hits 25455 25461 +6
- Misses 2481 2520 +39
|
There was a problem hiding this comment.
This is looking very promising. A few design questions arise.
As you note in filecoin-project/fvm-workbench#34, some tests are infeasibly slow to execute in a real VM. Whether or not we can improve some of them, we probably want some annotation ability at the point of export. Can we add that now? Two potential designs:
- a simple string annotation, into which we can conventionally pack a comma-separated list of tags or similar (flexible, less "safe")
- an integer to use as a set of flags, and some flag definitions here (perhaps just one for now, "SLOW" or similar)
This registry raises the idea of whether we can generate all the boilerplate entry points in test_vm/tests, both to remove the duplication and to exercise use of the registry here. That also raises a question about what impact removing the direct entry point code might have on development cycles. E.g. is the entry point name discoverable? Can IDEs easily run single tests
| let fn_name = &input_fn.sig.ident; | ||
|
|
||
| // Generate a unique identifier for the registration function | ||
| let register_fn_name = format_ident!("register_{}", fn_name); |
There was a problem hiding this comment.
Personally, I'd consider mangling this name to avoid conflicts.
|
@anorth
From my own setup and understanding, the IDEs will probably struggle to have a nice way to run individual tests. It also almagamates all the tests into one compilation target that needs to rebuild if any test is added/modified. I've left the existing entry points for now and left the test registry for external consumption only. |
I've already put them all in one target because it makes CI take much less time. For individual tests... ideally you'd be able to call: https://doc.rust-lang.org/stable/test/test/fn.parse_opts.html But that's unstable. However.... it should be possible to pass CLI options to one big test (for filtering). It'll kind of suck, but it'll also kind of work? |
|
Hm. Ok, so, another way is codegen. I.e., Then, in |
Uses a attribute macro to decorate tests that should be added to the exported registry.
Tests in the registry have their name derived by the function that was decorated.
The only test body that has changes is
placeholder_deploy_test. Other test bodies have not been changed (though that will most likely be required for a few in followup).