This does reduce our test coverage of basic composedb features a good amount though. I did this without modifying the body of any tests, just disabling any test that fails, but many of them fail just because the tests happens to check that the anchor status is PENDING in some place, without really relying on anchoring as a core part of the test. I could, instead, use the env var inside of test bodies to selectively skip just the parts of the tests that are breaking, but leaving the bulk of many of the tests in tact. It would just muddy up some of the tests a bit and to put them back later we'd have to grep for uses of the CERAMIC_RECON_MODE flag instead of just being able to search for testIfV3ShouldPassWithAnchoring and describeIfV3ShouldPassWithAnchoring.
I kind of think that would be a better way to go, but curious what others think.
EDIT: I went ahead and made the change. You can see the two different commits in this PR if you want to compare the difference in the two approaches.
linear[bot]
commented
8 months ago
This does reduce our test coverage of basic composedb features a good amount though. I did this without modifying the body of any tests, just disabling any test that fails, but many of them fail just because the tests happens to check that the anchor status is PENDING in some place, without really relying on anchoring as a core part of the test. I could, instead, use the env var inside of test bodies to selectively skip just the parts of the tests that are breaking, but leaving the bulk of many of the tests in tact. It would just muddy up some of the tests a bit and to put them back later we'd have to grep for uses of the
CERAMIC_RECON_MODEflag instead of just being able to search fortestIfV3ShouldPassWithAnchoringanddescribeIfV3ShouldPassWithAnchoring.I kind of think that would be a better way to go, but curious what others think.
EDIT: I went ahead and made the change. You can see the two different commits in this PR if you want to compare the difference in the two approaches.