On 02/04/2019 19:11, Brian Grinstead wrote:
I don't think that having papercuts in the workflow for writing one type of test is the right way to nudge developers into writing another type. It also doesn't seem effective - otherwise people would be using the wpt-create tool to avoid jumping through hoops to add a mochitest.
To be clear, my intent was not to add papercuts to any workflow; I'd really like all our developer workflows to be as ergonomic as possible, and adding better tooling to help people create tests seems like a great idea.
That said, there's a pattern that we've often fallen into where we make broadly applicable improvements to only a single testsuite — often mochitest — and then consider it to be job done. Although each change individually is small, over time it adds up and re-enforces an implied hierarchy of testsuites that doesn't match current best practices.
That said, given there’s already a convention for this perhaps the tool as-is would be better named `./mach mochitest-create`. Based on Steve’s suggestion, if we did want a single API we could do something like: # Attempt to automatically determine the type of test (mochitest-chrome, xpcshell, wpt, etc) `./mach addtest path/to/test` # If you want to pass extra arguments specific to that type, then you use a subcommand: `./mach addtest mochitest --flavor=chrome toolkit/components/windowcreator/test/test_chrome.html` `./mach addtest wpt testing/web-platform/tests/accelerometer/test.html --long-timeout`
I think the idea of a single mach command for test creation that, as far as possible, guesses the test type from its location is great. I'd be happy to provide whatever support is needed to make this replace the wpt-specific command.
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
