[webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

[Ryosuke Niwa]

On Fri, Oct 26, 2012 at 11:43 AM, Dirk Pranke <dpranke at chromium.org> wrote:

> On Fri, Oct 26, 2012 at 11:38 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > On Fri, Oct 26, 2012 at 11:33 AM, Elliott Sprehn <esprehn at chromium.org>
> > wrote:
> >>
> >> On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa <rniwa at webkit.org>
> wrote:
> >> > ...
> >> >
> >> > I agree this is a good change but it appears that we should add more
> >> > cache/loader tests before changing DRT's behavior given that there are
> >> > active contributors who rely on the current DRT behaviors to detect
> >> > regressions.
> >> >
> >>
> >> Can we add a flag to control this behavior? Then Antti could run the
> >> tests without cache clearing when modifying things possibly related to
> >> the cache code. We could even run a separate cr-linux bot like we do
> >> for debug builds.
> >
> >
> > I think having a set of tests that tests loaders/caches explicitly is
> more
> > useful.
> >
>
> I think having a set of tests for loaders and caches would be more
> useful as well, but I don't think it's fair to make that a requirement
> to changing the default behavior here, especially since it's not clear
> who all would be best suited to writing those tests or what the extent
> of that work is.
>

I’m sure Antti, Alexey, and others who have worked on the loader and other
parts of WebKit are happy to write those tests or list the kind of things
they want to test. Heck, I don’t mind writing those tests if someone could
make a list.

I totally sympathize with the sentiment to reduce the test flakiness but
loader and cache code have historically been under-tested, and we’ve had a
number of bugs detected only by running non-loader tests consecutively.

On the contrary, we’ve had this DRT behavior for ages. Is there any reason
we can’t wait for another couple of weeks or months until we add more
loader & cache tests before making the behavior change?

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121026/8771d31c/attachment.html>