I'm generally a fan of moving in the direction of using well-established, documented frameworks in order to reap network-effect benefits (good docs, tutorials, surprising behaviors/bugs are easy to find info about, etc). That said, one thing that people sometimes do when using mocha/jest-style nesting is to over-rotate on code-sharing at the cost of code readability ( https://kentcdodds.com/blog/avoid-nesting-when-youre-testing is worth a read), and I've certainly fallen into that trap. If we do go in a mocha/jest-like direction, I'd suggest we document a few best practices here (or maybe even just link to the blog post above) in our docs.
Dan On Thu, 24 Apr 2025 at 15:01, 'Nick Alexander' via [email protected] <[email protected]> wrote: > > > On Thu, Apr 24, 2025 at 6:08 AM 'Mark Banner' via [email protected] > <[email protected]> wrote: > >> On 11/04/2025 18:02, 'Nick Alexander' via [email protected] wrote: >> >> On Mon, Apr 7, 2025 at 9:24 AM 'Beth Rennie' via [email protected] >> <[email protected]> wrote: >> >>> Hi y'all, >>> >>> Last week I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1957513 >>> for investigating ways to improve mochitest and xpcshell-test tests for >>> Firefox Desktop. I initially was proposing a decorator based approach (à la >>> NormandyTestUtils [1]) but I've also implemented a mocha-ish to add_task >>> wrapper which is entirely opt-in. I've attached patches for both patterns >>> to the bug, as well as some additional patches which migrate a single test >>> (test_FirefoxLabs.js) to each of these patterns. >>> >>> I'm hoping this drives some discussion on these patterns (or other >>> potential patterns). Feedback is much appreciated. >>> >> >> Commenting here rather than on BZ in the hope that we spur more and >> broader discussion. >> >> I have often lamented not having richer testing primitives and support >> doing almost anything in the area to fill the gap. I am not familiar with >> Mocha but I am familiar with JUnit, which groups tests by classes in the >> namespace, and then exposes `{Before,After}Each` and `{Before,After}All` >> decorators (for per-test and per-suite setup and teardown, respectively). >> Right now we only have `BeforeAll` in the form of `add_setup`. I am not a >> fan of the `add_task` decorators that we currently have; they make it >> really quite awkward to add conditions to tests, so I would be happier if >> we exposed `add_cleanup`(for `AfterAll`) and perhaps >> `add_{before,after}_each` for the per-test variants. It's annoying to have >> to split tests across files in order to have fine-grained before/after >> configurations, but I'd prefer that to having to decorate every test and >> have many more awkward definitions than we already do. >> >> I'm not quite sure I understand the issue you're describing here. The >> main issue that I believe that this is intended to solve, is the case where >> we have multiple small tests which require set-up and tear-down for each >> individual test. Splitting those across files could mean many small files >> that are testing a single case only. Having before/afterEach would allow >> for those related tests to be in one file. I think you are saying that you >> would prefer those to be split across many files? If so, I think that >> there's probably a balance to be made as if it is many short tasks, then I >> think that would be harder to manage across multiple files. >> > The issue I'm describing is frustration using the existing condition > decorators, and not wanting to add more decorators when the existing ones > frustrate me. My experience with the condition decorators is that it's not > easy to compose them and leads to hard to read source files, i.e., adding > conditions tends to indent function bodies in difficult to control ways. > (Surely we could make it easier to compose conditions, but right now, we > haven't.). If beforeEach and afterEach are shared between many tests, then > having them in a separate file with function names in the namespace isn't a > great burden. If they're not shared, then there's less value in harness > support (but not no value). > > If Mocha and/or Jest have set a pattern in this space, then I am all for > following suit, for all of the reasons that you mention. I should be clear > that I will support and use almost any plausible expression of this idea. > > Glad to have spurred a little more discussion here :) > Nick > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAMnWBR1eu1Y-Q0agNwXKeK9LJaquZOY%3D8f8hkyNc455xq%2BXLMg%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAMnWBR1eu1Y-Q0agNwXKeK9LJaquZOY%3D8f8hkyNc455xq%2BXLMg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CABQdK3bUR229%3DjfxKa%2Bdxo1nZcf_Vksgs_V_SkVdmbk9Viffsw%40mail.gmail.com.
