-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'strict' Suite #32
Comments
@hugo-vrijswijk This sounds good to me. I do worry a bit about providing too many options. One of the things I really like about munit is that there aren't 25 style traits. Would be great to hear from others as to whether they'd use this feature. Maybe a proof of concept PR to get started? |
Yeah I'd be fine with starting on something. I definitely agree the perceived simplicity of munit is very nice to work with. Perhaps this feature would also be possible while keeping a single spec trait somehow? |
I spend a little bit of time on this, and didn't get very far. The problem is that munit has defined An alternative would be to add these two functions: def testIO(name: String)(body: => IO[Any])(implicit loc: Location): Unit = {
test(name)(body)
}
def testIO(options: TestOptions)(body: => IO[Any])(implicit loc: Location): Unit = {
test(options)(body)
} Upside being that it's very simple and all existing code is not touched. Downside is that What do you think? Would the above two functions add value? I could also go knocking on munit's door to change the |
MUnit allows overriding a
TestValue
to a value to enforce a test always returns that type. In the example it is used forFuture
.Due to the lazy evaluation of
IO
I think it'd be very useful if I could enforce my test would always return anIO
to prevent code from never being run. ScalaTest has recently changed their suites to beAnySpec
(can returnAny
) orAsyncSpec
(must return a Future). munit-cats-effect could introduce something similar for returnedIO
's by overriding MUnit'sTestValue
.If added to munits-cats-effect, users should probably still have a choice (just like in ScalaTest) between the two styles. And maybe 'strict' should not be the default? I don't have a strong opinion on what the naming should be.
For implementation some refactoring would probably be needed.
TestType
is made final inmunit.FunSuite
so the new suite would have to extend frommunit.Suite
. Code sharing between the two styles is probably also wanted. I'd be interested in helping out with a PR if this is wantedThe text was updated successfully, but these errors were encountered: