[Webkit-unassigned] [Bug 42603] Add a mock and LayoutTestController bindings for speech input.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=42603





--- Comment #7 from Satish Sampath <satish at chromium.org>  2010-07-27 15:05:33 PST ---
The goal is to mock WebCore::SpeechInputClient and use the mock in layout tests for testing the webcore code.

- Platform independant mock of WebCore::SpeechInputClient available in WebCore/platform/mock/SpeechInputClientMock.* (the non-mock implementation for chromium port is in WebKit/chromium/src/SpeechInputClientImpl.* for reference)
- WebViewImpl constructor decides whether to pass in the mock client or real client to WebCore::Page() based on the 'shouldUseMocks' flag. In the chromium port this is given by WebViewClient::shouldUseMocks()
- If the above shouldUseMocks flag is set, WebViewImpl creates a WebViewMocks object which holds all the mock objects, and it will use the mocks in place of real objects during this run.
- DumpRenderTree can access the mock object from WebView (e.g. to set mock results) by calling WebView::getMockObjects which returns the whole set of mocks. Adding new mocks requires no change in this call. DRT can call the respective mock interface to set the values for testing.
- The mocks themselves along with the WebViewMocks container object reside in a new platform independent WebKit/common directory, with /public holding headers which can be accessed by DRT and other embedders and /src holding the implementation. This code can be used across all c++ ports and new mocks can be added to this location along with other platform-independent code. The Mac port would probably have similar code in Obj-C under WebKit/mac.

I'd appreciate feedback on the overall design and code organisation. My reasoning to let WebKit decide to use mocks or real WebCore clients is that WebKit is the embedder for WebCore and the dependency injection decision is cleaner if done at this level. I also felt using a WebViewMocks-style test specific class would let us aggregate all tests related calls from DRT in a single place going forward, instead of polluting WebView directly.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.