Reorganize Marionette unit tests for better distinction between chrome and content tests

NEW
Unassigned

Status

defect
P3
normal
3 years ago
Last year

People

(Reporter: whimboo, Unassigned)

Tracking

(Blocks 1 bug)

Version 3
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Right now all Marionette unit tests have been thrown in a single folder and it's hard to see which are chrome or content. So before I start working on bug 1288336 I will reorganize those tests and tag them appropriately. 

It should also help us for bug 1297394 to lower the perma failures for Marionette tests for Fennec.
Priority: -- → P3
(In reply to Henrik Skupin (:whimboo) from comment #0)

> Right now all Marionette unit tests have been thrown in a single
> folder and it's hard to see which are chrome or content. So before
> I start working on bug 1288336 I will reorganize those tests and
> tag them appropriately.

I don’t understand exactly what you’re proposing to do here.  There
is a lot of interdependencies between chrome- and content tests
at the moment.  Typically we write the tests once for one of the
contexts, then have a subclass inherit from it to run them in a
different context.

This approach is not elegant, but works with the limitations imposed
on us by unittest.  If we were using pytest we could consider
parameterising them, but it still doesn’t address your point that
they are located in the same file/folder.
Flags: needinfo?(hskupin)
Ideally chrome tests should end-up in their own folder, so it's clear what only affects the client. But given that we want to port all (most) of the content context tests to wdspec, we could wait until this is done, and then only move the remaining content context tests into a subfolder.
Flags: needinfo?(hskupin)
What I’m trying to say is that we have two classes of chrome tests:
those that are already separate files testing specific chrome context
commands, and those that test commands shared between content-
and chrome context and which leviate the same test code as for content.

If you want to move the latter class of tests to separate files,
that necessarily entails code duplication.
There will be no code duplication once we were able to move all of the content tests to wdspec tests.
You need to log in before you can comment on or make changes to this bug.