Port JavaRosa `Scenario` test suites #110

If we pursue this, it’ll come after tests which are more pressing. If we decide not to, we can roll back this commit separately. Putting it in front because benchmarks were the first thing I noticed peeking back into JR for the first time in so long.

This change is being made now, as a response to repeatedly interrupting the porting effort as it became challenging to reason about which aspects of the `scenario` package come from JavaRosa (and should have stable semantics) versus aspects we’ve introduced to achieve those semantics (and should be more free to change as we move to support more of the JR test suite). Following this, we’ll break out many aspects of `Scenario`. Ideally, that class will only contain logic directly from JR or direct calls into code which is clearly **not** derived from JR.

Extends the built-in `expect` assertion factory to act on values with a `ComparableAnswer` interface. These interfaces will also be used for other assertion types beyond equality checks.

Despite the odd naming, I expect to find it much less fussy porting the remaining tests. And now, I believe we’re actually well prepared to start doing that!

This is a non-ideal solution (and loses a little bit of error messaging with better specificity), but it achieves the important goal **for now**: when a (synchronous) error is thrown during form initialization (and not caught anywhere else), the initialization Promise itself will reject. Otherwise, what happens is that the initialization Promise resolves, and then whatever error should have rejected it will be unhandled. This change (along with presumed future changes around conveying errors more broadly) will make it easier to reason about form load errors **happening**. It also makes it possible to properly mark a ported JavaRosa test as failing. It will otherwise report an out of band unhandled error, which is distinct from the expected failure.

This should provide better isolation between `Scenario`-based tests, by ensuring that any errors produced in (again, Scenario-internal) reactive computations are not treated as an “unhandled error” in subsequent tests (i.e. if they occur in the same event loop tick/microtask as the next test’s initialization, which itself currently queues a microtask to check that its initialization is complete).

…sertions

…e consistently

… hopefully the current usage, as well as JSDoc mostly allows this commit to speak for itself. Included in the same commit as it helped validate the abstraction (and the abstraction helped to address the change): when select choice labels are provided in an assertion, ensure those labels are always checked. Originally, only the choices’ values were being checked. After a clarifying discussion on Slack, it was decided that select choice labels will always be checked in assertions if present (even if they may be orthogonal to the test’s intent), to maximize the number of issues we can catch with such tests.

… to only wrap those tests clearly targeted for it

…Repeat parameter

JavaRosa’s implementation includes both signatures, somehow only the second one made it into the original iteration of this!

… presently skipping those which only assert evaluation counts

…etChild`

We’ll probably want to squash many of this branch’s commits. This one is only here so I can keep moving top down through JavaRosa’s test “bags”/“vats” (will never not be funny!), and so the next ported test can get a more meaningful commit note

This includes a faithful port, and a supplementary alternate version which checks for a different error message. The porting notes (marked as such in comments) go into more detail. But since a bit of thinking went into how to port this test and explain the reasoning, it also felt like it deserved a distinct commit (at least for review purposes).

…rise failure!

…th_cycles_*` tests

… repeats

… object

… with extensive porting notes mostly about casting semantics, and a couple of test variants demonstrating some of the factors at play in the original test/detailed in those notes.

- Test exercises what seems like various internals. Minimal effort has been made to satisfy those interfaces so they type check. - Test will fail before reaching those interfaces regardless. - Includes a supplemental test exercising some similar aspects of excluding non-relevant nodes - Supplemental test fails, caught a bug!

Also concerned with repeats. Includes note about potentially breaking out test modules specifically organized around intersecting concerns.

… note recommendation to use negation of `toBeReadonly` assertion rather than the less clearly named `toBeEnabled` custom assertion also introduced in this commit.

…e group

This is the first which hadn’t already been ported as part of the early prototype/spike/project validation effort.

…g repeats”

… this is a pre-meeting checkpoint, capturing as many tests as I could before we potentially re-scope/re-prioritize.

…correctly updated)

Separate commit mostly to show why the ancillary interface/classes are added.

- Includes extension of `JRFormDef` interface to support direct port - Includes alternate approach with only `Scenario` APIs - Includes note about providing such alternates for all like tests which will follow

- Fixes an apparent mixup with two different partial/fake `TreeReference` ports - Adds and immediately deprecates a custom assertion for that type - Deviates from general porting process, to include failure analysis of the last included test (nested relevance). There was enough weirdness here that it felt reasonable to spend an hour of this quiet Saturday morning getting a better understanding (especially since I ended the previous day with much deeper confusion about the test, and the likely cause of its failure)

…created Includes an alternate approach to the test with a proposed method on Scenario. The direct port fails on invocation of `FormDef` equivalent APIs we don’t expect to port. The alternate fails because we don’t currently support the functionality.

…utput … and an alternate approach, with proposed extension to `Scenario` API as opposed to further use of APIs corresponding to JavaRosa internals

…output Includes two alternates: 1. Adapt direct port to use proposed `Scenario` API 2. Fix apparent mistakes in test: it doesn’t exercise `jr:itext`, correctly close the itext id attribute Adds proposed `labelRef` to form fixture DSL.

…lity

- Introduces `typeofAssertion` factory. This can be used for **more than** primitives, but that’s the use case it’s being introduced for now. Being general purpose, the types also support narrowing specific non-`unknown` types, including some care taken to specifically apply narrowing for unions including: - specific object types - non-specific functions without a known signature - specific function signatures - class constructors (which may or may not be abstract) - Not particularly noteworthy, but this finally introduces the `AnyFunction` type. I have nearly added this type at least a dozen times, but in each case found another approach. This is a type with lots of utility because it is somehow distinct from `Function` in narrowing, but should be used sparingly (usually to restrict the range of types assignable for a particular type parameter). - Adapts the various uses of `Inspectable` to support inspection (in our usage, serialization to a dev-facing but human-readable string; this is still a WIP) of most non-object types. This allows us to generalize error conditions when assertions fail, and when the assertion’s comparison has a primitive `expected` value.

To be used in tests in the format: ```ts expect(ComparableAnswer).toStartWith(‘expected prefix’); ``` This is intended as a strawman, we should probably reconsider either the naming, the signature, or both. (Discussed in detail in the method’s JSDoc)

- Skips direct port, as it seems likely to be a unit-ish test. - Adds an alternate using `Scenario`-oriented APIs. Test may be redundant to others, but included for now in the spirit of completeness

- Adds proposed `Scenario` API with roughly equivalent semantics to the ported tests’ calls into JavaRosa internals - Includes supplemental tests and corresponding `Scenario` API proposal, asserting **all** of the available select items’ labels against the same form definitions in the ported tests.

Per discussion in Slack, we’re porting these as TODO tests pending prioritization of the functionality. There are too many concepts with unclear applicability to port the test logic reasonably at this time.

I’ve been mulling how to address test “vats” we’ve skipped in this porting process. I think for now it makes sense to at least include detailed notes where they might apply. In this case, the test “vat” has been waiting in my local `pending` directory for some resolution, and it makes sense to clear it out. If any of the other remaining “vats” fall into this category, they may be included in this subdirectory with a similar structure. Regardless, I’ll try to summarize what was skipped once a full port PR is ready.

Static title test fails, translated title test is skipped with some discussion of potential spec implications.

Nearly everything is skipped, lots of notes taken, lots of questions about mental model and intent raised.

There may be additional test logic we can repurpose into `Scenario` APIs or testing other layers, but this at least tests: - Any of the tests from the “vat” exercising `Scenario` APIs - Initialization of all other forms under test in the “vat” A few failures, and behavior clarifications, come out of this as well.

This comment previously discussed earlier Scenario initialization logic, which was invalidated around the time the logic was moved here.

- Call them out as from JR - Add link to context

Others can get updated as we work on these

… and remove superfluous/previously commented out `scenario.newInstance` calls in that suite as well as the very similar SelectMultipleChoiceFilterTest.java.

… and related, mistaken commentary about whether the JavaRosa comment was associated with the wrong test.

There are more that could be updated. It’ll get tedious. This commit will hopefully serve as a reminder that both of these rephrasings were agreed in review.

Others like this can follow suit when we get to them

…elpful.”

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Port JavaRosa `Scenario` test suites #110

Port JavaRosa `Scenario` test suites #110

Commits on May 28, 2024

Commits on May 29, 2024

Commits on May 30, 2024

Port JavaRosa Scenario test suites #110

Port JavaRosa Scenario test suites #110

Commits on May 28, 2024

Commits on May 29, 2024

Commits on May 30, 2024

Port JavaRosa `Scenario` test suites #110

Port JavaRosa `Scenario` test suites #110