Suggestion: Method to convert TestMessage[] to marble string in TestScheduler

[samal-rasmussen]

Old ticket that wasn't completely addressed, so I'm trying a new ticket: #2620

Suggestion:
It would be helpful if TestScheduler exposed a way to convert TestMessage[] to a marble string for easier comparisons when debugging.

I see @kwonoj has an implementation right here that could maybe be borrowed:
https://github.com/kwonoj/rx-sandbox/blob/master/src/assert/constructObservableMarble.ts
https://github.com/kwonoj/rx-sandbox/blob/master/src/assert/constructSubscriptionMarble.ts

[kwonoj]

Moved into discussion since this is not a bug.

There were some internal discussions around different assertion suite and what we want to do in the future, but we don't have conclusion yet. After those rx-sandbox have some diverged interfaces along with its DSL definitions compare to built in testscheulder which makes codes are not directly usable. At this point I don't have strong desire to port things over into testscheduler.

[samal-rasmussen]

Thanks for looking at this again.

After those rx-sandbox have some diverged interfaces along with its DSL definitions compare to built in testscheulder which makes codes are not directly usable

I'm not an expert on TestScheduler so pardon my ignorance, but what codes are you referring to here? This?
https://github.com/kwonoj/rx-sandbox/blob/master/src/marbles/ObservableMarbleToken.ts
https://github.com/kwonoj/rx-sandbox/blob/master/src/marbles/SubscriptionMarbleToken.ts

So I came up with two use cases for having a built in feature for converting from TestMessage[] to a marble string:

• Stronger ability to use TestScheduler without a testing framework (this is what I was doing).
• A canonical TestMessage[] to marbe string implementation that can be shared between testing frameworks, and also allows new testing frameworks to quickly implement better support for marble string assertions.

At this point I don't have strong desire to port things over into testscheduler.

Would you be opposed if someone else did it?

[samal-rasmussen]

Another implementation in jasmine-marbles:
https://github.com/synapse-wireless-labs/jasmine-marbles/pull/55/files

[cartant]

IMO any attempt at implementing this should probably wait until the marble syntax has been revisited, as it's likely it will change so that scenarios that cannot currently be represented can be. See #5523

There are also issues with the explicit time specification syntax that have been discussed in core team meetings. IIRC there are higher-priority items and it was decided that revisiting the marble syntax can wait until we have restructured into a mono repo with a separate testing module - offering a deprecation path for the current syntax.