dbus: verify object path of incoming signals

dbus/end_to_end_async_unittest.cc

Index: dbus/end_to_end_async_unittest.cc
diff --git a/dbus/end_to_end_async_unittest.cc b/dbus/end_to_end_async_unittest.cc
index 9a88b42cffec6d1830bd479ab8b9bb9a3a5ee8ca..967b35ce1b47abaddd80eececec4ad3267fd7e39 100644
--- a/dbus/end_to_end_async_unittest.cc
+++ b/dbus/end_to_end_async_unittest.cc
@@ -160,6 +160,17 @@ class EndToEndAsyncTest : public testing::Test {
     message_loop_.Run();
   }
 
+  // Wait for the hey signal to be received, or a timeout.
+  void WaitForTestSignalOrTimeout(int timeout_ms) {
+    // OnTestSignal() will quit the message loop, we don't expect that
+    // to be called, so post a delayed task to quit the message loop
+    // for when it isn't.
+    message_loop_.PostDelayedTask(FROM_HERE,
+                                  MessageLoop::QuitClosure(),
+                                  timeout_ms);
+    message_loop_.Run();
+  }
+
   MessageLoop message_loop_;
   std::vector<std::string> response_strings_;
   scoped_ptr<base::Thread> dbus_thread_;
@@ -302,11 +313,13 @@ TEST_F(EndToEndAsyncTest, TestSignal) {
 
 TEST_F(EndToEndAsyncTest, TestSignalFromRoot) {
   const char kMessage[] = "hello, world";
-  // Send the test signal from the root object path, to see if we can
-  // handle signals sent from "/", like dbus-send does.
+  // Object proxies are tied to a particular object path, if a signal
+  // arrives from a different object path like "/" the proxy should not
+  // handle it, and should leave it for another.
   test_service_->SendTestSignalFromRoot(kMessage);
-  // Receive the signal with the object proxy. The signal is handled in
-  // EndToEndAsyncTest::OnTestSignal() in the main thread.
-  WaitForTestSignal();
-  ASSERT_EQ(kMessage, test_signal_string_);
+  // Timeout while waiting to receive the signal, failing if we received it.
+  const int timeout_ms = 5000;
+  WaitForTestSignalOrTimeout(timeout_ms);

[satorux1, 2012/03/01 00:14:32]

Does this mean the test takes 5 seconds to perform? It's a bit too long for a
unit test. We should probably use action_timeout_ms() in
base/test/test_timeouts.h

[keybuk, 2012/03/01 00:15:22]

yes.

action_timeout_ms is 10s, which is even longer

but tiny_timeout_ms was too short to guarantee the signal got through dbus (the
test failed 3/7 times I tried)

[satorux1, 2012/03/01 00:23:46]

I see. Then let's remove this test. 

A better way to test this is to check if ObjectProxy rejects  signals from wrong
senders, but we don't have ability to observe the behavior from outside.

+  // Verify the signal was not received
+  ASSERT_TRUE(test_signal_string_.empty());
 }