Add service unittest for WakeLockServiceImpl.

device/power_save_blocker/power_save_blocker_x11.cc

Index: device/power_save_blocker/power_save_blocker_x11.cc
diff --git a/device/power_save_blocker/power_save_blocker_x11.cc b/device/power_save_blocker/power_save_blocker_x11.cc
index 8c96590eaab5f29bf88ce0662560af775c9dc893..3a77287647b1d7fa0440202d1cd5e807e8bd8e3f 100644
--- a/device/power_save_blocker/power_save_blocker_x11.cc
+++ b/device/power_save_blocker/power_save_blocker_x11.cc
@@ -441,6 +441,10 @@ bool PowerSaveBlocker::Delegate::XSSAvailable() {
   if (base::CommandLine::ForCurrentProcess()->HasSwitch(switches::kHeadless))
     return false;
   XDisplay* display = gfx::GetXDisplay();
+  // In service_unittests context, XDisplay is not well initialized. passing a

[blundell, 2017/05/16 13:37:55]

Did you check whether it's possible to initialize XDisplay instead?

[ke.he, 2017/05/17 07:19:54]

Yes, I followed how the browser_main_runner.cc initializes the x11, calling
gfx::InitialzieThreadedX11(), and the XDisplay can be initialized successfully.
But again powerSaveBlocker crashes on some place related to D-BUS. So, still
complex.

I feel that this unittest is for the WakeLockServiceImpl and its mojo
interfaces, so I stopped digging on why the PowerSaveBlocker doesn't work on
DeviceServiceTestBase. Maybe in future it blocks something, I will continue to
fix it then. Do you think it is OK?

[blundell, 2017/05/17 09:01:42]

Short-circuiting out early in the test isn't concerning; my concern is only that
now we're adding a path for silent failure in production code that wasn't there
before. I think maybe it would be a better to add an OS_LINUX-specific
DisableXSSForTest() method to PowerSaveBlocker?

+  // nullptr to XScreenSaverQueryExtension() will cause crash.
+  if (!display)
+    return false;
   int dummy;
   int major;
   int minor;