test(toh-[234]): add e2e for Dart and TS

[chalin]

From the user's perspective toh-2 to -4 all have the same behavior.
This PR introduces e2e tests for all these parts by sharing test suites.

3 minor bugs were detected by the tests and are fixed in this PR.

The toh-1 tests introduced in #1620 are

• Refactored so as to be easier to reuse for the other parts.
• Rewritten to benefit from the availability of async/await.

Suites passed:

• public/docs/_examples/toh-1/dart
• public/docs/_examples/toh-1/ts
• public/docs/_examples/toh-2/dart
• public/docs/_examples/toh-2/ts
• public/docs/_examples/toh-3/dart
• public/docs/_examples/toh-3/ts
• public/docs/_examples/toh-4/dart
• public/docs/_examples/toh-4/ts

Contributes to #1619.

Fixes #1609.
Now the toh-4 index.html is identical to those of the previous parts.

[chalin]

@Foxandxss @filipesilva @kwalrath @thso : ready for review.

[Foxandxss]

I have mixed feelings about this. I understand that the tests shares a lot, but I feel like the tests are now a bit overkill for what they should accomplish.

But that is just me :/

[chalin]

Do you mean "overkill" in the sense that too much functionality is being tested?

[chalin]

On the good side, the tests did uncover (minor) problems with the apps. :)

[Foxandxss]

Overkill in terms that we are creating too many files for something that should be simple.

And yes, that is the good side of tests.

I want the tests, that for sure. I also understand that toh is an special case for this.

[chalin]

Right, this is a special case. The given module breakdown allows toh-2, -3, and -4 to reuse the same tests (because the app changes are only internal). This makes for DRY tests.

[chalin]

The alternative would be to copy-paste tests, which I think we prefer not doing.

[filipesilva]

All for tests factoring and reusability. The other option is to use Page Objects with some kind of extention/inheritance but would still imply a fair bit of copy paste so I don't think it's ideal.

[chalin]

Thanks for pointing out page objects (the getPageElts() was a crude approximation of using a page object); it is nice to know about that idiom.

Is there any chance that this might get reviewed and merged before the long week-end? :)

[filipesilva]

It lgtm tbh.

[wardbell]

Sorry but I have a different perspective on this.

I'm generally in favor of DRY. But not when it comes to sharing content-specific material/tests across samples. Test infrastructure? Of course we do! But specific tests? I'm uncomfortable with that.

Why? Because it binds the toh parts together. Now I can break tests for toh-2 when I make changes to toh-4. I don't like that kind of vulnerability.

I DO like that you uncovered some bugs. Let's fix those independently.

Otherwise, ... sorry ... I'm declining this PR.

Leaving it open (briefly) to allow comments and so you can mine the bug fixes in a separate PR.

[chalin]

@wardbell : thanks for the feedback. Allow me to defend this approach one last time (in case it might waver your opinion). I generally agree with you points (e.g., if this were test infrastructure sharing between unrelated chapters), but:

• The toh parts are semantically bound; they are a progression by design.
• If ever a scenario like the one you described occurs (making changes to tests for toh-x breaks the tests for toh-y), then the fix is easy:
  • copy-paste shared files to break the coupling between toh-x and toh-y.

Given the tight coupling between the toh parts, by design, I believe that sharing some test infrastructure has more benefits than risks. And essentially what you are asking me to do now is to proactively ditch the DRYness rather than do it down the line if/when it is needed. My 2 cents. Let me know what you think.

[wardbell]

I'm sorry, Patrice, but I'm going to have to insist on the "non-DRY" part. I hate doing that. I hate it more because my instincts align with yours. But that just isn't how ToH is set up.

Observe that the ToH code samples do not share code. They too are far from DRY. Your argument in favor of DRY would apply equally there. And yet we didn't do it. Why?

Because we decided - rightly or wrongly - to insulate each ToH tutorial for its comrades. If we change that, we can change the tests. I don't think we should be DRY in the tests and WET in the code.

We don't have time to revisit that decision now.

I'm sorry. Hate to be heavy handed. Please forgive me.

[chalin]

I understand your reasons. Will split this up into two PRs (fixes vs e2e tests) and make the e2e tests independent as you recommend. Thanks for hearing me out.

[chalin]

Superseded by #1934, #1936, #1938, #1939, #1940.