On 11/04/2025 18:02, 'Nick Alexander' via firefox-...@mozilla.org wrote:
On Mon, Apr 7, 2025 at 9:24 AM 'Beth Rennie' via
dev-platform@mozilla.org <dev-platform@mozilla.org> 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 reason that I suggested a Mocha (Jest is also an option) like
interface for enabling this, is that this will help move our test
infrastructure towards standard JavaScript testing mechanisms, rather
than our own custom functions. Eventually we could potentially replace
our current harnesses with an appropriate library.
I think heading towards this style of decorators should help with
onboarding new developers, as we would be providing a test
infrastructure that's more familiar. There may also be tooling benefits
we can get from it as well, e.g. both Mocha & Jest have associated
ESLint plugins.
Mark
--
You received this message because you are subscribed to the Google Groups
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-platform+unsubscr...@mozilla.org.
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/b4ee47d0-4ffc-49e4-8784-1b1f8ed19979%40mozilla.com.
