On Fri, Nov 23, 2012 at 1:34 AM, Henrik Skupin <[email protected]> wrote:
> [email protected] wrote on 11/21/12 9:28 AM: > > > 1. Any work Henrik already started for certain crashtests (since I > > know he's got a few in queue) - finish those off > > The primarily work I wanted to do here is done now. I have investigated > our two blockers which prevents us from turning on crashtests on > mozilla-central. Those are now in developers hands. That means today I > will get some of the crashtests written for still broken cases. I will > not spend more than half a day on it. > > > 2. Henrik shifts focus towards smoke test automation for the full > > stack, I'll finish off the gUM smoke test automation (which is 90% > > done). > > To combine what everyone else said, what do you want me to start on > first? Are these gUM or PeerConnection tests? I think with Jasons basic > gUM tests we have a good first start once landed, and I should do a > similar thing for the peerconnection piece. PC. What we need is something analagous to the tests we have in C++ (signaling_unittests.cpp) though perhaps not quite as aggressive about testing a pile of SDP variants. > > 3. We establish a review policy that any patches that can definitely > > have a crashtest associated with them has to be included on check-in > > by the developer building the patch. If the patch comes in without a > > crashtest that can indeed possibly have one, the patch gets a review- > > until the test is included. That will balance both validating that > > the patch actually does work at check-in, but also starts to burn > > through progressively building out a crashtest regression automation > > suite. > > I would love that because of: > > * it helps devs to check that the crash has been fixed across platforms > by pushing it to try (via the alder branch for now) instead of only > testing it on their own platform work happens. > > * crashtests are easy to create from the already attached testcases. I agree with Randell that while this may be good practice in many cases, it's not a reasonable general policy as a gating factor on checkin. As I said, to the extent to which test cases are already available (or Test develops them) I agree that they should pass, but I don't think it's a requirement that the developers write them for every crash. -Ekr _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
