The manner in which TestScheduler parses a frame-group seems wrong/counter-intuitive?

[RobertDiebels]

I am not sure whether this is a bug or working as intended so I thought I'd ask a question instead.

Given the documentation regarding time-progression syntax, stating:

'--(abc)-|': on frame 2 emit a, b, and c, then on frame 8, complete.

what I would expect to be the case would be:

on frame 2 emit a, b, and c, then on frame 4, complete.

It seems as if the parenthesis are counted as a frame and each value-emission within that frame is also counted as a frame.
This seems wrong to me but it could also be working as intended.
If it is working as intended I would really love to know why this is the case and would advocate for adding that explanation to the documentation.

Testing with:

TestScheduler.parseMarbles('(tf)(tf)', {t: true, f: false});

Gives me:

[{"frame":0,"notification":{"kind":"N","value":true}},{"frame":0,"notification":{"kind":"N","value":false}},{"frame":40,"notification":{"kind":"N","value":true}},{"frame":40,"notification":{"kind":"N","value":false}}]

While I would expect:

[{"frame":0,"notification":{"kind":"N","value":true}},{"frame":0,"notification":{"kind":"N","value":false}},{"frame":10,"notification":{"kind":"N","value":true}},{"frame":10,"notification":{"kind":"N","value":false}}]

How would I test a scenario where I have 2 emissions per frame? Is that a valid scenario? Or are frames implicitly bound to a single emission?

[lgpage]

Hi @RobertDiebels

This is as intended. From the the RxJS docs:

While it can be unintuitive at first, after all the values have synchronously emitted time will progress a number of frames equal to the number of ASCII characters in the group, including the parentheses. e.g. '(abc)' will emit the values of a, b, and c synchronously in the same frame and then advance virtual time by 5 frames, '(abc)'.length === 5 . This is done because it often helps you vertically align your marble diagrams, but it's a known pain point in real-world testing.

[RobertDiebels]

Thanks for the quick response!

Just to get this straight. The only reason this exists is because of aesthetics?

So, say I have an operator that takes an input observable and produces an output observable which emits the same values just doubles the emission per frame.
Then the only way for me to test that operator with marble-syntax is by altering the input marble or using an actual observable?

For instance:

 it('should emit twice per frame', () => {
        testScheduler.run(({cold, expectObservable}) => {
            // Assemble
            const input = cold('t---f', {t: true, f: false}); // This input does not represent expected input observable ('tf').

            function doubleEmissions(input: Observable<boolean>): Observable<boolean> {
                return new Observable((subscriber) => {
                    input.subscribe({
                        next(value) {
                            subscriber.next(value);
                            subscriber.next(value);
                        }
                    });
                });
            }

            // Act
            const actual: Observable<boolean> = doubleEmissions(input);
            // Assert
            expectObservable(actual).toBe('(tt)(ff)', {t: true, f: false});
        });
    });

In other words to test multiple emissions per frame with marble-syntax I have to create an inaccurate representation of my input to match the output of the marbles? Is there a way around this? Should I just be comparing regular Observables with one another in this case?

[lgpage]

Hi @RobertDiebels

I can't speak to the design decisions for the test scheduler in RxJs, but here are related issues:

• Marble complete not respecting group frames #6931
• Limitation in marble testing use cases due to grouping semantics #5677

You can also look into using https://github.com/kwonoj/rx-sandbox for testing

[RobertDiebels]

Thanks for the reply!
I marked this as the answer and I'll check if that FR can be brought back to live.
Since it seems a bit odd to me to support frame-groups but require changing test-code to do so.
Either way, thanks!