Allow tests to be selected by name.

Allow tests to be selected by name.

Closes #7

R=kevmoo@google.com

Committed: https://github.com/dart-lang/unittest/commit/64dfda5c1fc9423acd59801f44c075085bfdd283

[kevmoo, 2015-03-28 22:02:26]

Also: running this pub 'pub downgrade' – even when adding string_scanner,
crashes.

I think we have some too-forgiving pub versions

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart
File bin/unittest.dart (right):

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart#newcode32
bin/unittest.dart:32: 'Regular expression syntax is supported.');
In theory I like regex support, but since we allow tests to have any name – even
regex "special" chars, I'd almost want regexp parsing to be opt-in (or at least
opt-out).

Makes it a lot easier to safely tool, etc

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml
File pubspec.yaml (left):

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml#oldcode9
pubspec.yaml:9: analyzer: '>=0.23.0 <0.25.0'
Missing a dependency on string_scanner

[nweiz, 2015-03-30 19:45:41]

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart
File bin/unittest.dart (right):

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart#newcode32
bin/unittest.dart:32: 'Regular expression syntax is supported.');
On 2015/03/28 22:02:26, kevmoo wrote:
> In theory I like regex support, but since we allow tests to have any name
– even
> regex "special" chars, I'd almost want regexp parsing to be opt-in (or at
least
> opt-out).

I personally hate it when I have to switch up my command-line flags to enable
regexps in a tool. I think it's very unlikely to cause problems. The most common
regexp-active character is ".", which will still match a literal ".", and even
if the test name does contain something like "+" or "()", mostly this flag will
just be passed a couple adjacent words so that won't come up in practice.

> Makes it a lot easier to safely tool, etc

I don't know what this means.

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml
File pubspec.yaml (left):

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml#oldcode9
pubspec.yaml:9: analyzer: '>=0.23.0 <0.25.0'
On 2015/03/28 22:02:26, kevmoo wrote:
> Missing a dependency on string_scanner

This isn't relevant to this CL, correct?

[kevmoo, 2015-03-30 19:51:49]

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart
File bin/unittest.dart (right):

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart#newcode32
bin/unittest.dart:32: 'Regular expression syntax is supported.');
On 2015/03/30 19:45:41, nweiz wrote:
> On 2015/03/28 22:02:26, kevmoo wrote:
> > In theory I like regex support, but since we allow tests to have any name
> – even
> > regex "special" chars, I'd almost want regexp parsing to be opt-in (or at
> least
> > opt-out).
> 
> I personally hate it when I have to switch up my command-line flags to enable
> regexps in a tool. I think it's very unlikely to cause problems. The most
common
> regexp-active character is ".", which will still match a literal ".", and even
> if the test name does contain something like "+" or "()", mostly this flag
will
> just be passed a couple adjacent words so that won't come up in practice.

I'm fine if plain text is opt in. But we should absolutely support plain text.

> > Makes it a lot easier to safely tool, etc
> 
> I don't know what this means.

Safely tool: I can wrap the command line API with a dumb script that just sends
an identical String match without having to worry about making them regex
friendly

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml
File pubspec.yaml (left):

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml#oldcode9
pubspec.yaml:9: analyzer: '>=0.23.0 <0.25.0'
On 2015/03/30 19:45:41, nweiz wrote:
> On 2015/03/28 22:02:26, kevmoo wrote:
> > Missing a dependency on string_scanner
> 
> This isn't relevant to this CL, correct?

Nope. Just noticed it.

[nweiz, 2015-03-30 20:08:09]

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart
File bin/unittest.dart (right):

https://codereview.chromium.org/1041503002/diff/1/bin/unittest.dart#newcode32
bin/unittest.dart:32: 'Regular expression syntax is supported.');
On 2015/03/30 19:51:49, kevmoo wrote:
> On 2015/03/30 19:45:41, nweiz wrote:
> > On 2015/03/28 22:02:26, kevmoo wrote:
> > > In theory I like regex support, but since we allow tests to have any name
> > – even
> > > regex "special" chars, I'd almost want regexp parsing to be opt-in (or at
> > least
> > > opt-out).
> > 
> > I personally hate it when I have to switch up my command-line flags to
enable
> > regexps in a tool. I think it's very unlikely to cause problems. The most
> common
> > regexp-active character is ".", which will still match a literal ".", and
even
> > if the test name does contain something like "+" or "()", mostly this flag
> will
> > just be passed a couple adjacent words so that won't come up in practice.
> 
> I'm fine if plain text is opt in. But we should absolutely support plain text.
> 
> > > Makes it a lot easier to safely tool, etc
> > 
> > I don't know what this means.
> 
> Safely tool: I can wrap the command line API with a dumb script that just
sends
> an identical String match without having to worry about making them regex
> friendly

Done.

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml
File pubspec.yaml (left):

https://codereview.chromium.org/1041503002/diff/1/pubspec.yaml#oldcode9
pubspec.yaml:9: analyzer: '>=0.23.0 <0.25.0'
On 2015/03/30 19:51:49, kevmoo wrote:
> On 2015/03/30 19:45:41, nweiz wrote:
> > On 2015/03/28 22:02:26, kevmoo wrote:
> > > Missing a dependency on string_scanner
> > 
> > This isn't relevant to this CL, correct?
> 
> Nope. Just noticed it.

That's a good time to file an issue :).

[kevmoo, 2015-03-30 20:13:15]

lgtm

[nweiz, 2015-03-30 21:23:47]

Committed patchset #3 (id:40001) manually as
64dfda5c1fc9423acd59801f44c075085bfdd283 (presubmit successful).