pkg/unittest: config refactor

pkg/unittest/lib/compact_vm_config.dart

 // Copyright (c) 2013, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 /**
  * A test configuration that generates a compact 1-line progress bar. The bar is
  * updated in-place before and after each test is executed. If all test pass,
  * you should only see a couple lines in the terminal. If a test fails, the
  * failure is shown and the progress bar continues to be updated below it.
  */
@@ skipping 153 matching lines @@
     var res = text.substring(text.length - maxLength + 4);
     var firstSpace = res.indexOf(' ');
     if (firstSpace > 0) {
       res = res.substring(firstSpace);
     }
     return '...$res';
   }
 }
 
 void useCompactVMConfiguration() {
-  if (config != null) return;

[Siggi Cherem (dart-lang), 2013/03/24 17:20:09]

Let's keep this part (here and in the other configurations).

It's ok for config = X to throw, but we should still make it easy to compose
test files together. In particular, we commonly write tests in multiple files
like this:

feature1_test.dart:
  main() { useXConfiguration(); ... some tests }

feature2_test.dart:
  main() { useXConfiguration(); ... some tests }

all_features_test.dart:
  import 'feature1_test.dart' as f1;
  import 'feature2_test.dart' as f2;
  main() {
    useXConfiguration();
    f1.main();
    f2.main();
  }


True - people would have the alternative to write the code as follows:

feature1_test.dart:
  main() { if (config == null) useXConfiguration(); ... some tests }

feature2_test.dart:
  main() { if (config == null) useXConfiguration(); ... some tests }

all_features_test.dart:
  import 'feature1_test.dart' as f1;
  import 'feature2_test.dart' as f2;
  main() {
    if (config == null) useXConfiguration();
    f1.main();
    f2.main();
  }

but I think the whole purpose of 'useXConfiguration' is to make these use cases
simple and make life easier for users of unittest. We can add a documentation
comment on each of this useXConfig explaining things, if you like.

[kevmoo-old, 2013/03/24 18:00:02]

How about Configuration classes implement

bool operator ==

And the setter checks to see if the new value and old value are equal. If yes,
then it's a no-op.

We get the best of both:

Composition of related tests: goodness.
Errors if someone tries to set multiple, incompatible configs.

[Siggi Cherem (dart-lang), 2013/03/24 18:18:42]

Could be. One reason I'm not entirely sure is that I can imagine users wanting
to use a more detailed configuration when running a subset of the test, and a
more compact config when running all tests together.

Note that even if we implement 'operator ==', we can't replace the
configuration. If we do, then we might get to an inconsistent state inside
unittest (it relies on calling init and start on the same configuration,
otherwise bad things happen).

Here is another (similar) idea, instead of overriding '==', define a singleton
for each configuration. That way, if you call useXConfiguration twice, you are
basically assigning exactly the same instance and everything just works.

final _singleton = new CompactVMConfiguration();
void useCompactVMConfiguraiton() {
  config = _singleton;
}


Then, config's setter can check:
set config(newConfig) {
  if (_config != null || !identical(_config, newConfig)) { error... }
  ...
}

-  configure(new CompactVMConfiguration());
+  config = new CompactVMConfiguration();
 }