[webkit-dev] Sharing WebKit mocks across platforms

[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 <ap at webkit.org> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
morrita