Add output formatters for more mojom types.

mojo/public/cpp/bindings/tests/formatting_unittest.cc

Index: mojo/public/cpp/bindings/tests/formatting_unittest.cc
diff --git a/mojo/public/cpp/bindings/tests/formatting_unittest.cc b/mojo/public/cpp/bindings/tests/formatting_unittest.cc
new file mode 100644
index 0000000000000000000000000000000000000000..90822437a7bf39877fc21f3ca76fb575a51e1e39
--- /dev/null
+++ b/mojo/public/cpp/bindings/tests/formatting_unittest.cc
@@ -0,0 +1,104 @@
+// Copyright 2016 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 <sstream>
+
+#include "mojo/public/cpp/bindings/array.h"
+#include "mojo/public/cpp/bindings/formatting.h"

[viettrungluu, 2016/01/26 23:19:40]

nit: The convention is to include the particular file, in this case
formatting.h, first in the unit test. (Not a big deal -- it helps to check that
the .h file is independently compilable when there's no .cc file.)

[jeffbrown, 2016/01/26 23:40:46]

Yeah, none of the other unit tests in this directory do that so I followed the
local convention.  Ordinarily I do as you suggest.

+#include "mojo/public/cpp/bindings/map.h"
+#include "mojo/public/interfaces/bindings/tests/test_structs.mojom.h"
+#include "testing/gtest/include/gtest/gtest.h"
+
+namespace mojo {
+namespace test {
+namespace {

[viettrungluu, 2016/01/26 23:19:40]

Note: You can probably put everything in an anonymous namespace (the only thing
which you may not be able to put in there are the operator<<s), including the
TEST() { ... } parts.

[jeffbrown, 2016/01/26 23:40:46]

Acknowledged.

+RectPtr MakeRect(int32_t factor = 1) {
+  RectPtr rect(Rect::New());
+  rect->x = 1 * factor;
+  rect->y = 2 * factor;
+  rect->width = 10 * factor;
+  rect->height = 20 * factor;
+  return rect;
+}
+}  // namespace
+
+std::ostream& operator<<(std::ostream& os, const Rect& value) {
+  return os << "{x=" << value.x << ", y=" << value.y
+            << ", width=" << value.width << ", height=" << value.height << "}";
+}
+
+std::ostream& operator<<(std::ostream& os, const RectPair& value) {
+  return os << "{first=" << value.first << ", second=" << value.second << "}";
+}
+
+TEST(FormattingTest, Arrays) {
+  Array<int32_t> null_array;
+  Array<int32_t> empty_array;
+  empty_array.resize(0);
+  Array<int32_t> one_element_array;
+  one_element_array.push_back(123);
+  Array<int32_t> three_element_array;
+  three_element_array.push_back(4);
+  three_element_array.push_back(5);
+  three_element_array.push_back(6);
+
+  std::ostringstream so;
+  so << "null_array=" << null_array << ", empty_array=" << empty_array
+     << ", one_element_array=" << one_element_array
+     << ", three_element_array=" << three_element_array;
+
+  EXPECT_EQ(
+      "null_array=null, "
+      "empty_array=[], "
+      "one_element_array=[123], "
+      "three_element_array=[4, 5, 6]",
+      so.str());
+}
+
+TEST(FormattingTest, Maps) {
+  Map<int32_t, std::string> null_map;
+  Map<int32_t, std::string> empty_map;
+  empty_map.mark_non_null();
+  Map<int32_t, std::string> one_element_map;
+  one_element_map.insert(123, "abc");
+  Map<int32_t, std::string> three_element_map;
+  three_element_map.insert(4, "d");
+  three_element_map.insert(5, "e");
+  three_element_map.insert(6, "f");
+
+  std::ostringstream so;
+  so << "null_map=" << null_map << ", empty_map=" << empty_map
+     << ", one_element_map=" << one_element_map
+     << ", three_element_map=" << three_element_map;
+
+  EXPECT_EQ(
+      "null_map=null, "
+      "empty_map={}, "
+      "one_element_map={123: abc}, "

[viettrungluu, 2016/01/26 23:19:40]

Side comment (not for this CL -- for future reference):

It'd be nice if abc were quoted here, which indicates the desirability of some
distinction along the lines of Python's str() vs repr() ("%s" vs "%r")....

I wonder if the right thing to do isn't to have formatting functions (whether
they deal with strings or streams; I guess streams are more general)
included/available everywhere, and then have formatting.h use those functions
(picking either repr or str).

[jeffbrown, 2016/01/26 23:40:46]

Starting to think you may be right, but the lack of quotes should make it clear
why I did the array-style thing before since it tended to be less ambiguous.  :)

Some kind of overloaded mojo::Format function might do nicely.  Stuff to think
about later.

+      "three_element_map={4: d, 5: e, 6: f}",
+      so.str());
+}
+
+TEST(FormattingTest, Structs) {
+  InlinedStructPtr<Rect> inlined_struct_ptr = MakeRect(1);
+  InlinedStructPtr<Rect> null_inlined_struct_ptr;
+  StructPtr<RectPair> struct_ptr = RectPair::New();
+  struct_ptr->first = MakeRect(2);
+  StructPtr<RectPair> null_struct_ptr;
+
+  std::ostringstream so;
+  so << "inlined_struct_ptr=" << inlined_struct_ptr
+     << ", null_inlined_struct_ptr=" << null_inlined_struct_ptr
+     << ", struct_ptr=" << struct_ptr
+     << ", null_struct_ptr=" << null_struct_ptr;
+  EXPECT_EQ(
+      "inlined_struct_ptr={x=1, y=2, width=10, height=20}, "
+      "null_inlined_struct_ptr=null, "
+      "struct_ptr={first={x=2, y=4, width=20, height=40}, second=null}, "
+      "null_struct_ptr=null",
+      so.str());
+}
+
+}  // namespace test
+}  // namespace mojo