On 02/09/2016 13:49, Henrik Skupin wrote:
Gijs Kruitbosch wrote on 09/02/2016 11:37 AM:
We should be doing the same for firefox-ui tests. Not just to avoid
duplication of files in archives, but because otherwise, if we want to
add new tests somewhere else, we both have to add the manifests to the
build system and then modify this build system python file to make sure
they get included in the test archive. That would be wrong.
No, this is not what we want to do. Anything related to the obj dir
causes a lot of operations and cpu cycles to build those archives (see
bug 1283919 comment 1).
This comment has no information at all about operations or cpu cycles,
so I don't follow.
With having the manifests in place we can also
run the tests directly from the source tree.
I don't understand what this sentence actually means. We have manifests
for all our test suites - it doesn't seem to have any direct bearing on
whether they can be run from the source tree or not (mochitests have
manifests and can't be run from the source tree today, AIUI). What point
are you trying to make?
It's true that the
situation with a master manifest is not ideal right now, and especially
for marionette we have it located in
testing/marionette/harness/marionette/test/. Anyway for firefox-ui tests
I want to have testing/firefox-ui/tests/(functional|update)-tests.ini.
From here we can reference everything.
So what's the proposal? This is no longer clear to me. You want to keep
a single manifest somewhere under testing/, and then have the actual
test files spread around the tree?
It would seem to make more sense to have individual manifests for the
different bits. That's certainly more scalable and maintainable (ie have
it be obvious why and when which tests run, and not have a motley
collection in a single manifest file) and helps preserve infra resources
as well, because we make decisions about what builds/tests to run based
on the paths of files modified. It's not sensible that whenever I would
want to write a patch and accompanying test, I have to modify files in
testing/marionette/harness or testing/firefox-ui/tests/ .
It's not clear to me why marionette and firefox-ui don't use the same
moz.build infrastructure to collect test manifests and thereby test
files as mochitest/xpcshell/reftests, and why we couldn't use exactly
that infrastructure to determine what to stick in the test archives as
far as the tests themselves are concerned. The mixing of information
storage here (in both directory naming/structure and manifest files)
only leads to duplication and confusion/bugs.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
