New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 675027 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
rbyers@chromium.org
█ aelias@chromium.org
dtapu...@chromium.org
mustaq@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Unit test coverage for base/touch

Project Member Reported by mustaq@chromium.org, Dec 16 2016 
We don't seem to have a way to "snapshot" web-exposed behaviors that are platform specific. LayoutTests expectations are good for web-exposed behaviors but they exclude platforms differences.

One recent example: media query evals are platform dependent. The only layout-test we have (fast/media/mq-pointer.html) avoids platform differences by testing setters/getters only. As a result, a web-exposed regression in Android code ( Issue 672907 ) went unnoticed for 2+ months until it was in stable!

For media-queries, we need to have platform-specific (or even device-specific) expectations somehow to catch such regressions in future.

There could be similar cases for other tests.

I see that global-interface-listing has Windows-specific expectations (through a virtual test suite). May be we should have more of these?

Comment 1 by rbyers@chromium.org, Dec 16 2016

Cc: aelias@chromium.org
I don't think the platform-specific part should be a problem today.  If necessary we can have either platform-specific exepectation files, or just have if/#ifdef checks in the test to expect different things on different platforms (not ideal, but I'm sure we've already got examples).

Is't the hard part here that it's really device dependent not platform dependent?  Eg. would we really want a test that would fail if the Android drive happened to have a mouse plugged in?

We could perhaps have some sort of browser integration test that mocks out the lowest level in a platform-specific way - but depending on exactly how we did that it may or may not catch  issue 672907 .  This is a general problem with testing hardware APIs (just like testing input - what if our synthetic input pipeline is fine but there's a bug in the non-synthetic path).

Maybe there are OS-provided primitives for faking the available input devices at the OS level that we could use from tests?  That seems like it's probably a lot of work though - likely not worth it.

Another pragmatic option is that perhaps we should just have some sort of unit test coverage for the TouchDevice APIs in base?

Comment 2 by aelias@chromium.org, Dec 16 2016 

Integration tests and device-specific tests are really burdensome to maintain.  We need to weigh that against the benefit.  This isn't really a major problem area justifying a new category of test, judging by the fact that this is the first time this happened in a couple of years.  So I'd favor the pragmatic approach of "unit test coverage for the TouchDevice APIs".

Comment 3 by nzolghadr@chromium.org, Dec 14 2017 

Still an issue Q4 2017 checkin

Comment 4 by mustaq@chromium.org, Jun 18 2018

Summary: Unit test coverage for base/touch (was: Catching web-exposed platform-specific regressions)
Switching the bug title to the pragmatic option proposed in #c1.
►

Sign in to add a comment