matcher: should be their own pkg

[jmesserly]

I don't think matchers depend on unittest. Presumably they should not be in the unittest pkg?

[gramster]

I felt that way too but I think there was some pushback. If nothing else separating them out would mean they actually show up in API docs!

[DartBot]

This comment was originally written by [email protected]

---

Issue #3717 is of historical significance here.

[munificent]

I'm fine with splitting them up. I think at the time our package reuse story wasn't quite as mature. We were still using SDK packages and the version solver wasn't as smart. Today, it should be easier to split these up while still being easy for users to consume them.

Would unittest.dart will export matchers.dart, or would users have to import both in their tests?

[sigmundch]

I'd be happy to split them up, but I'd prefer if unittest reexports them by default.

[gramster]

My assumption was that if we split them up, unittest would not import matcher, and so users would import both if they wanted to use out matchers and expect(). OTOH they could use a different matcher library if they want.

[gramster]

We do have a different issue, which is asking for unittest to be renamed unit_test to be consistent with the style guide. So an option - although it's kinda hokey - would be to move unittest to unit_test, and have unittest be a shell that imports and reexports unit_test and matcher. That would mean we don't break any existing tests.

[gramster]

The renaming issue is https://code.google.com/p/dart/issues/detail?id=10120

[sigmundch]

Not sure.

I'd do the unittest exports unit_test + matchers just as a transition, maybe include a deprecation message so that users start switching their imports.

If people already have to rewrite their imports because we rename the package to 'unit_test', then that would be a great point to do a few other things like:

• introduce new entrypoint files for each configuration (so instead of import unittest + import vm_config, you just import 'package:unit_test/vm_testing.dart')
• maybe not including 'matchers' by default

I personally prefer that matchers is included because the great majority out there just wants to use it together with unittest, so there is less set up to do. If we don't it with unittest.dart, do people need to also add a pub dependency to get matchers?

[munificent]

• introduce new entrypoint files for each configuration (so instead of import unittest + import vm_config, you just import 'package:unit_test/vm_testing.dart')

I'm hesitant to do this because I worry it means people will couple their unit tests to a single configuration even when the code under test can run on multiple configs.

• maybe not including 'matchers' by default

I believe unittest is and will be coupled to matcher, it's just that matcher is not coupled to unittest.

If we don't it with unittest.dart, do people need to also add a pub dependency to get matchers?

No, unittest depends on it, so you will get it transitively automatically.

[gramster]

Removed the owner.
Added Triaged label.

[DartBot]

This comment was originally written by @seaneagan

---

Any updates on this? I have some use cases for matchers outside of unit testing, and it's weird to have to include unittest to get to them. It also seems error prone, as unittest is often a dev_dependency, so it would work in development, but fail in production when unittest no longer appears in the "packages" dir.

[kevmoo]

Added Pkg-matcher label.

[kevmoo]

matcher has been its own package for a month+ now

Closing now that unittest no longer exports it: r35954

---

Added Fixed label.

[DartBot]

This issue has been moved to dart-lang/test#2331.