Skip to content
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 doobie-munit package to integrate Doobie with the shiny new MUnit #1233

Merged
merged 28 commits into from
May 23, 2021

Conversation

Kazark
Copy link
Contributor

@Kazark Kazark commented Jul 13, 2020

MUnit is a the new Scala testing framework on the block. Seems reasonable for Doobie to support it along with the other two it already supports.

I copied off scalatest because it is fairly similar to MUnit. Hopefully I didn't forget to change anything after the copy and paste, particularly in the documentation (the test is green, at least).

Keith Pinson added 2 commits July 13, 2020 11:54
MUnit is a the new Scala testing framework on the block. Seems reasonable for
Doobie to support it along with the other two it already supports.

I copied off `scalatest` because it is fairly similar to MUnit. Hopefully I
didn't forget to change anything after the copy and paste, particularly in the
documentation (the test is green, at least).
@@ -99,7 +99,7 @@ def biggerThan2(minPop: Int) =
biggerThan2(0).check.unsafeRunSync
```

**doobie** supports `check` for queries and updates in three ways: programmatically, via YOLO mode in the REPL, and via the `doobie-specs2` and `doobie-scalatest` packages, which allow checking to become part of your unit test suite. We will investigate this in the chapter on testing.
**doobie** supports `check` for queries and updates in four ways: programmatically, via YOLO mode in the REPL, and via the `doobie-specs2`, `doobie-scalatest` and `doobie-munit` packages, which allow checking to become part of your unit test suite. We will investigate this in the chapter on testing.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take or leave it: might a bulleted list be easier to view?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's a reasonable idea; the general principle of the PR was to try to stick closely with what's there. We'll see what @tpolecat says.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idm what's currently here, since it's featured prominantly in 13-Unit-Testing.md :)

```scala mdoc:silent
import munit._

class AnalysisTestScalaCheck extends FunSuite with doobie.munit.IOChecker {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does FunSuite come from munit, @Kazark ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

@alejandrohdezma
Copy link
Contributor

Hi @tpolecat, any chance on taking a look at this? I've been copying @Kazark implementation around and it will be super if we could have this integration out of the box 😸

@tpolecat
Copy link
Member

This looks fine, sorry for the delay. I'll merge it if you bring it up to date.

@Kazark
Copy link
Contributor Author

Kazark commented Nov 18, 2020

Thanks @alejandrohdezma

@alejandrohdezma
Copy link
Contributor

alejandrohdezma commented Nov 18, 2020

@tpolecat done! I've included an update of the setup-scala Github Action since the build was broken without it

@alejandrohdezma
Copy link
Contributor

Hey @tpolecat, I have conform doobie-munit with the latest changes in doobie-specs2. Do you think this is ready to merge now?

@jatcwang jatcwang self-requested a review January 28, 2021 11:17
@FunFunFine
Copy link

So when can we expect this one released?

@jatcwang
Copy link
Collaborator

There are a few thing left that we need to release 0.11 so I've asked Rob to look at a few important PRs (including this one). No ETA sorry.

Comment on lines +51 to +58
val report = analyzeIO(args, transactor).unsafeRunSync()
if (!report.succeeded) {
fail(
formatReport(args, report, colors)
.padLeft(" ")
.toString
)
}
Copy link

@ValdemarGr ValdemarGr Mar 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't levering https://github.com/typelevel/munit-cats-effect be a better choice?
Something like.

Suggested change
val report = analyzeIO(args, transactor).unsafeRunSync()
if (!report.succeeded) {
fail(
formatReport(args, report, colors)
.padLeft(" ")
.toString
)
}
val report = analyzeIO(args, transactor)
report.flatMap{
case r if !r.succeeded =>
IO(fail(
formatReport(args, report, colors)
.padLeft(" ")
.toString
))
case _ => IO.unit
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have implemented the munit-cats-effect integration at
https://github.com/ValdemarGr/doobie/tree/munit
Can someone give any insight or consideration for the idea?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a good idea. It'll also make CE3 migration easier

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implementation also changes the semantics of check; it is no longer eager, is this desired?
The scalatest and specs2 test utilities seem to be eager.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If execution thread gets to check(..) then we're running the test already right? (This PR's impl seems eager to me, unless I'm missing something)

munit (and all other test frameworks that I know) all use call-by-name to allow skipping tests, so test("asdf") { check(..) } is still skippable even if check is eager.

Copy link

@ValdemarGr ValdemarGr Mar 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah I think the other integrations (scalatest/specs) run it eagerly. Perhaps it is worth keeping that behaviour to make it easier for people to migrate between test libs. (I know that in my codebase I have a few check(..) being called as if they're statements)

So I guess cats-effect munit won't help us here. Sorry!

@hamnis
Copy link
Contributor

hamnis commented May 20, 2021

at $WORK we would really like to leave scalatest in the dust, so this would help a lot. Can we get this going again?

@jatcwang
Copy link
Collaborator

Sorry just saw that I needed to approve the CI.
@tpolecat I've approved the PR. Merge it if you're happy with it too :)

@jatcwang
Copy link
Collaborator

Thanks for the PR and sorry for the delay! I'll get this merged into the cats-effect 3 (1.x) branch too.

@jatcwang jatcwang merged commit a8021d1 into typelevel:master May 23, 2021
@Kazark Kazark deleted the munit branch May 24, 2021 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants