Sorry for a delayed response - I hoped for someone else to weigh in. This approach is certainly better than having code in shipping WebCore. But I still think that testing via platform APIs is much more desirable than implementing and maintaining a separate "pseudo-API" for mocks. This can't be too bad for productivity either - the social contract seems to be that you implement DumpRenderTree for one or two platforms at most, and file bugs for others.
- WBR, Alexey Proskuryakov 27.10.2010, в 22:08, Hajime Morita написал(а): > Hi Alexey, thank you for revising this topic! > > I understand your concern about having a testing infrastructure inside > the production code. > On the other hand, having separate but similar mocks for each port > hurts our productivity. > And we cannot automate testing without mocks anyway. > > So how about to have separate "WebCoreTesting" library/framework? > The WebCoreTesting will: > - access WebCore types directly, as WebKit library does > - have mock implementations of WebCore-provided interfaces (abstract classes) > and > - WebCore will provide abstract classes and injection points for their > intenaces, but not provide class implementations > - WebKit will provide a priviate method to enable the mocks, which > uses WebKitTesting. > WebKitTesting library will be linked lazily (using weak symbol > mechanism for Mac, or dlopen() family for other ports.) > > In this approach, we > - can split the testing infrastructure out from the production code, > just by removing WebCoreTesting library. > - can share mock implementations between ports. > > Even with this approach, some redundancy remains in WebCore, like > abstract class for mocks. > But actual code, which is a possible cause of vulnerability, can be > removed from the production. > > I once prototyped that approach for introducing WebCore::LayoutTestController. > So the patch might help to see what I meant to say: > https://bug-42612-attachments.webkit.org/attachment.cgi?id=63403 > (Note this patch has rough edges and need to polish anyway.) > > Believing what I proposed above is a reasonable tradeoff between > security/efficiency and productivity, > I wonder there might be other possibilities to explore. > So I'd love to hear from you and any folks who have interest. > > Regards. > -- > morrita > > > On Thu, Oct 28, 2010 at 4:07 AM, Alexey Proskuryakov <[email protected]> wrote: >> >> 02.08.2010, в 4:38, Alexey Proskuryakov написал(а): >> >>> >>> 29.07.2010, в 8:16, Adam Barth написал(а): >>> >>>> Plumbing this mock API all the way through WebKit for each port seems like >>>> a waste. >>> >>> >>> One benefit of this is that it makes us test the API layer. Another one is >>> that it gives WebKit developers better familiarity with APIs - that's not >>> as minor as it sounds, as some of us (including myself) have limited >>> knowledge of WebKit APIs, even for their favorite platform. >>> >>> It certainly seems like a waste when private methods are added just for >>> DumpRenderTree support. But maybe it has prompted an API introduction a few >>> times before, I just don't know. >>> >>> This is all getting much better with WebKit2's cross-platform API, although >>> of course we'll need to support current APIs for a long time. >> >> This thread died, but I still don't feel good about mock objects in WebCore. >> Having test infrastructure in WebCore means shipping unused code in the >> framework, and as mentioned before, we lack testing of the API layer. >> >> We're now getting more mock objects in the tree, such as one for speech >> synthesis testing. >> >> - WBR, Alexey Proskuryakov >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > > -- > morrita _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
