[Autofill] Add protobuf for Google Wallet risk parameters and a utility function for filling it out.

chrome/browser/autofill/risk/fingerprint_browsertest.cc

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/autofill/risk/fingerprint.h"
+
+#include "base/bind.h"
+#include "base/message_loop.h"
+#include "base/prefs/public/pref_service_base.h"
+#include "chrome/browser/autofill/risk/proto/fingerprint.pb.h"
+#include "chrome/common/pref_names.h"
+#include "chrome/test/base/in_process_browser_test.h"
+#include "chrome/test/base/testing_pref_service.h"
+#include "testing/gtest/include/gtest/gtest.h"
+#include "ui/gfx/rect.h"
+
+namespace autofill {
+namespace risk {
+
+namespace {
+
+const int64 kGaiaId = 99194853094755497;
+const char kCharset[] = "UTF-8";
+const char kAcceptLanguages[] = "en-US,en";
+
+}  // namespace
+
+class AutofillRiskFingerprintTest : public InProcessBrowserTest {
+ public:
+  AutofillRiskFingerprintTest()
+      : kWindowBounds(2, 3, 5, 7),
+        kContentBounds(11, 13, 17, 37),
+        message_loop_(MessageLoop::TYPE_UI) {}
+
+  void GetFingerprintTestCallback(scoped_ptr<Fingerprint> fingerprint) {
+    // Verify that all fields Chrome can fill have been filled.
+    ASSERT_TRUE(fingerprint->has_machine_characteristics());
+    const Fingerprint_MachineCharacteristics& machine =
+        fingerprint->machine_characteristics();
+    ASSERT_TRUE(machine.has_operating_system_build());
+    ASSERT_TRUE(machine.has_browser_install_time_ms());
+    ASSERT_GT(machine.font_size(), 0);
+    ASSERT_GT(machine.plugin_size(), 0);
+    ASSERT_TRUE(machine.has_utc_offset_ms());
+    ASSERT_TRUE(machine.has_browser_language());
+    ASSERT_GT(machine.requested_language_size(), 0);
+    ASSERT_TRUE(machine.has_charset());
+    ASSERT_TRUE(machine.has_screen_count());

[Evan Stade, 2012/12/21 22:37:08]

does this mean the test will fail on a headless machine? Is it normal that a
browser test would fail if no screen is attached?

[Ilya Sherman, 2012/12/22 01:22:00]

The test would still pass on a headless machine.  There's a difference between
explicitly setting the default value (which is 0) for an optional field vs.
leaving the field entirely unset.  This checks that the value has been set, but
not what it has been set to.

+    ASSERT_TRUE(machine.has_screen_size());
+    ASSERT_TRUE(machine.screen_size().has_width());
+    ASSERT_TRUE(machine.screen_size().has_height());
+    ASSERT_TRUE(machine.has_user_agent());
+    ASSERT_TRUE(machine.has_cpu());

[Evan Stade, 2012/12/21 22:37:08]

do all of these need to be ASSERT instead of EXPECT?

[Ilya Sherman, 2012/12/22 01:22:00]

Some of them need to be ASSERTs for the sake of subsequent checks, e.g.
EXPECT_EQ(kCharset, machine.charset());  Given that some have to be ASSERTs for
that reason, I'd rather have them be uniform than having to reason about each of
them whether it could be an EXPECT -- especially since that would then
potentially need to be updated when the test is updated.

As a side note, I've never identified a good reason for using EXPECTs when
ASSERTs will also compile.  Tests either pass or fail; I don't see much value in
running extra checks within a single test if it's already failed.  But since the
common Chrome coding practice seems to be to prefer EXPECT checks, I try to use
them where they're obviously sufficient.

[Evan Stade, 2012/12/22 02:17:34]

EXPECT cuts down on the number of fix-compile-run cycles you need to do when you
make a change that breaks a test. This is especially important when the
compile-run cycle takes 2 hours because it's a trybot on a configuration you
don't have local access to. As you've noted, it's not the end of the world if
you have an ASSERT instead of an EXPECT, but the reverse is also true: it's not
that bad to EXPECT instead of ASSERT, because a crashing test is also a failing
test.

You already separated some of the checks into their own blocks based on check
relatedness. You could do this in more places (e.g. the cpu checks, graphics
card checks, etc.) and each block will start with an ASSERT followed by many
EXPECTs. I think this improves readability.

[Ilya Sherman, 2012/12/26 23:10:28]

Fair enough, though for this particular test's ASSERTs, there shouldn't be any
behavioral differences that depend on the build configuration.  (There are also
git cl try command flags that you can pass to reduce the cycle time if you're
debugging a specific test, but that's somewhat tangential.)
The test is currently split into two parts: (1) checking that the expected
fields are set in the protocol buffer, and (2) checking that some mocked values
were written correctly.  I tried interleaving these, which is what you're
suggesting, and found it both less readable -- because the test was bouncing
back and forth between different types of checks -- and less maintainable --
because you'd have to remember to change specific EXPECTs to ASSERTs as more
values were mocked out.

+    ASSERT_TRUE(machine.cpu().has_vendor_name());
+    ASSERT_TRUE(machine.cpu().has_brand());
+    ASSERT_TRUE(machine.has_ram());
+    ASSERT_TRUE(machine.has_graphics_card());
+    ASSERT_TRUE(machine.graphics_card().has_vendor_id());
+    ASSERT_TRUE(machine.graphics_card().has_device_id());
+    ASSERT_TRUE(machine.has_browser_build());
+
+    ASSERT_TRUE(fingerprint->has_transient_state());
+    const Fingerprint_TransientState& transient_state =
+        fingerprint->transient_state();
+    ASSERT_TRUE(transient_state.has_inner_window_size());
+    ASSERT_TRUE(transient_state.has_outer_window_size());
+    ASSERT_TRUE(transient_state.inner_window_size().has_width());
+    ASSERT_TRUE(transient_state.inner_window_size().has_height());
+    ASSERT_TRUE(transient_state.outer_window_size().has_width());
+    ASSERT_TRUE(transient_state.outer_window_size().has_height());
+
+    ASSERT_TRUE(fingerprint->has_metadata());
+    ASSERT_TRUE(fingerprint->metadata().has_timestamp_ms());
+    ASSERT_TRUE(fingerprint->metadata().has_gaia_id());
+    ASSERT_TRUE(fingerprint->metadata().has_fingerprinter_version());
+
+    // Some values have exact known (mocked out) values:
+    ASSERT_EQ(2, machine.requested_language_size());
+    EXPECT_EQ("en-US", machine.requested_language(0));
+    EXPECT_EQ("en", machine.requested_language(1));
+    EXPECT_EQ(kCharset, machine.charset());
+    EXPECT_EQ(kContentBounds.width(),
+              transient_state.inner_window_size().width());
+    EXPECT_EQ(kContentBounds.height(),
+              transient_state.inner_window_size().height());
+    EXPECT_EQ(kWindowBounds.width(),
+              transient_state.outer_window_size().width());
+    EXPECT_EQ(kWindowBounds.height(),
+              transient_state.outer_window_size().height());
+    EXPECT_EQ(kGaiaId, fingerprint->metadata().gaia_id());
+
+    message_loop_.Quit();
+  }
+
+ protected:
+  const gfx::Rect kWindowBounds;
+  const gfx::Rect kContentBounds;
+  MessageLoop message_loop_;
+};
+
+// Test that getting a fingerprint works on some basic level.
+IN_PROC_BROWSER_TEST_F(AutofillRiskFingerprintTest, GetFingerprint) {
+  TestingPrefService prefs;
+  prefs.RegisterStringPref(prefs::kDefaultCharset, kCharset,
+                           PrefServiceBase::UNSYNCABLE_PREF);
+  prefs.RegisterStringPref(prefs::kAcceptLanguages, kAcceptLanguages,
+                           PrefServiceBase::UNSYNCABLE_PREF);
+
+  GetFingerprint(
+      kGaiaId, kWindowBounds, kContentBounds, prefs,
+      base::Bind(&AutofillRiskFingerprintTest::GetFingerprintTestCallback,
+                 base::Unretained(this)));
+
+  // Wait for the callback to be called.
+  message_loop_.Run();
+}
+
+}  // namespace risk
+}  // namespace autofill