Formatter checkpoint.

editor/tools/plugins/com.google.dart.engine_test/src/com/google/dart/engine/formatter/CodeFormatterTest.data

Index: editor/tools/plugins/com.google.dart.engine_test/src/com/google/dart/engine/formatter/CodeFormatterTest.data
===================================================================
--- editor/tools/plugins/com.google.dart.engine_test/src/com/google/dart/engine/formatter/CodeFormatterTest.data	(revision 15190)
+++ editor/tools/plugins/com.google.dart.engine_test/src/com/google/dart/engine/formatter/CodeFormatterTest.data	(working copy)
@@ -1,10 +1,28 @@
 <<<<

[Brian Wilkerson, 2012/11/21 15:02:46]

Not that I'm asking for a change, but it would be nice if there were a way to
document the purpose for each test (such as "extra space before class name",
etc.)

Here's another idea: if testing that extra spaces disappear is one general style
of test, it kind of seems like a set of tests that define valid results then
produce tests by replacing each span of whitespace characters (spaces, tabs,
end-of-line markers) with a different span of whitespace characters and
verifying that the formatted result is equal to the original might be much less
verbose and far more complete.

[pquitslund, 2012/11/21 18:17:09]

Good deal.  I'm increasingly on the fence about the value of the existing
approach so your thoughts are most welcome.  My current thinking is that these
particular tests will serve as a final phase integration test.  And that the
preceding tests will behave more like unit tests in the way you describe.

More on that soon! :)

-class A{
+class  A {
 }
 >>>>
 class A {
 }
 <<<<
+class B  {
+}
+>>>>
+class B {
+}
+<<<<
+class C  {
+}
+>>>>
+class C {
+}
+<<<<
+class D  extends B  {
+}
+>>>>
+class D extends B {
+}
+<<<<
 class A {}
 >>>>
 class A {