On 11/04/2019 18:22, Brian Grinstead wrote:
This has now landed (with initial support for xpcshell, mochitests, and web
platform tests). Thanks to Andrew Halberstadt and James Graham for improving
upon the initial prototype and making it easier to extend to new suites.
Eager users should note
This has now landed (with initial support for xpcshell, mochitests, and web
platform tests). Thanks to Andrew Halberstadt and James Graham for improving
upon the initial prototype and making it easier to extend to new suites.
If the suite supports it (currently xpcshell and mochitests), we will
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 thr
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.
That said, giv
This sounds great! One nit - could this be done also for unit
(xpcshell) tests? good examples are in netwerk/test/unit/ and unit_ipc/.
Thanks!
-hb-
On 2019-04-01 20:54, Jared Hirsch wrote:
This sounds great! I land features in the tree periodically, but
infrequently enough to forget lots of l
On 01/04/2019 23:13, Steve Fink wrote:
On 4/1/19 11:36 AM, Brian Grinstead wrote:
Based on my own experience and discussions with others, the workflow
for adding new mochitests isn't great. Commonly, it looks like:
"copy/paste a test in the same directory, add the new test to the
relevant mani
I was hoping that other types could be added over time, so making the name
generic was intentional. It will already error if you try to add something that
doesn’t look like a mochitest, but it’s a good suggestion to make that more
obvious. I can file bugs for other test types and then include th
On 4/1/19 11:36 AM, Brian Grinstead wrote:
Based on my own experience and discussions with others, the workflow for adding new
mochitests isn't great. Commonly, it looks like: "copy/paste a test in the same
directory, add the new test to the relevant manifest file, empty out the actual test
bi
> On Apr 1, 2019, at 11:54 AM, Jared Hirsch <6...@mozilla.com> wrote:
>
> This sounds great! I land features in the tree periodically, but infrequently
> enough to forget lots of little details. It would really save time (mine and
> the time of people I ping on IRC for help...) if our tooling
> On Apr 1, 2019, at 12:38 PM, Brian Grinstead wrote:
>>> Links to bugs/comments/etc can be added in the test if they are relevant,
>>> but I don't know that it's important enough to add another step in front of
>>> getting a useful test case built. I did also consider adding a TODO comment
>>
> On Apr 1, 2019, at 12:23 PM, Felipe G wrote:
>
> Something that would be a nice flare would be if it got the information from
> the moz.build file to tell which component the new file would be related to.
>
> Definitely not essential, though.
I think that would be doable, though I don’t kn
> On Apr 1, 2019, at 12:15 PM, Boris Zbarsky wrote:
>
> On 4/1/19 2:36 PM, Brian Grinstead wrote:
>> When you run the command it will create a file with the appropriate
>> boilerplate and add it to the manifest file (chrome.ini, mochitest.ini,
>> browser.ini depending on the type).
>
> Brian
Something that would be a nice flare would be if it got the information
from the moz.build file to tell which component the new file would be
related to.
Definitely not essential, though.
And a question: will it also work if you're already in the right dir and
just specifies the filename? That's
On 4/1/19 2:36 PM, Brian Grinstead wrote:
When you run the command it will create a file with the appropriate
boilerplate and add it to the manifest file (chrome.ini, mochitest.ini,
browser.ini depending on the type).
Brian, thank you for putting this together!
I have one concern with the m
This sounds great! I land features in the tree periodically, but
infrequently enough to forget lots of little details. It would really save
time (mine and the time of people I ping on IRC for help...) if our tooling
simplified the process of creating new tests.
I don't have any historical context
Based on my own experience and discussions with others, the workflow for adding
new mochitests isn't great. Commonly, it looks like: "copy/paste a test in the
same directory, add the new test to the relevant manifest file, empty out the
actual test bits, write your test". In my experience this i
16 matches
Mail list logo
