Confirmed users
656
edits
Dev-sanity: Difference between revisions
→Unified interface for running tests
| Line 61: | Line 61: | ||
== Unified interface for running tests == | == Unified interface for running tests == | ||
Every test harness has its own set of arguments and quirks. It's also not entirely obvious which suite has tests for feature X. It requires some guess work to figure out how to test a particular feature thoroughly. We are slowly moving away from a "suite centric" approach to a "feature centric" one. The end goal is for a developer to say which part of the code they want to test, and for the automation to figure out what it needs to do to accomplish that. Developers shouldn't have to know or care that it's necessary to run mochitest chrome with --subsuite push to test a given component. | |||
This is already partly implemented by the |mach mochitest| command that will figure out all the flavors and subsuites that exist in a given directory, and by the |mach test| command that will find which test harnesses have tests in the given directory. There is still a lot of work to do here though. |mach test| doesn't support every suite and it doesn't work with b2g. The output from running multiple suites one after another doesn't get summarized nicely and |mach test| doesn't support the full set of command line options that you get when running the various suites directly (this is mostly due to the fact that the harnesses don't share the same names for their cli arguments). The end goal is for most developers using |mach test [path/to/dir/or/test]| to run their tests, no matter the suite, flavor or platform. | |||
= Others? = | = Others? = | ||