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.
3 years ago
(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.
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.
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.