Skip to content

Commit

Permalink
Minor fixes in blog post
Browse files Browse the repository at this point in the history
  • Loading branch information
Olafur Pall Geirsson committed Feb 1, 2020
1 parent 7bdb238 commit a4ba585
Showing 1 changed file with 21 additions and 20 deletions.
41 changes: 21 additions & 20 deletions website/blog/2020-02-01-hello-world.md
Original file line number Diff line number Diff line change
Expand Up @@ -129,10 +129,11 @@ object Windows213 extends Tag("Windows213")
class MySuite extends FunSuite {
// reminder: type Test = GenericTest[Any]
override def munitNewTest(test: Test): Test = {
val isIgnored = !options.tags(Windows213) || {
Properties.isWin &&
Properties.versionNumberString.startsWith("2.13")
}
val isIgnored =
options.tags(Windows213) && !(
Properties.isWin &&
Properties.versionNumberString.startsWith("2.13")
)
if (isIgnored) test.withBody(() => Ignore)
else test
}
Expand All @@ -141,7 +142,7 @@ class MySuite extends FunSuite {
// Only runs when operating system is Windows and Scala version is 2.13
}
test("normal test") {
// Always runs.
// Always runs like a normal test.
}
}
```
Expand Down Expand Up @@ -179,7 +180,7 @@ behavior of your program has changed.
In the image above, the failing `assertNoDiff()` includes a `stripMargin`
formatted multiline string of the obtained string. The `assertNoDiff()`
assertions is helpful for comparing multiline strings ignoring non-visible
differences such as Windows/Unix newlines, ANSI colors and leading/trailing
differences such as Windows/Unix newlines, ANSI color codes and leading/trailing
whitespace.

![Demo showing how to include clues in error messages](https://i.imgur.com/Iy82OWe.png)
Expand All @@ -190,28 +191,28 @@ with additional information that is displayed when the assertion fails.
![Demo showing highlighted stack traces](https://i.imgur.com/iosErEv.png)

In the image above, stack trace elements that are defined from library
dependencies like the standard library are grayed making it easier to find stack
trace elements from your own code. This can be helpful when debugging exceptions
with cryptic error messages. This feature is inspired by
[utest](https://github.com/lihaoyi/utest).
dependencies like the standard library are grayed out making it easier to find
stack trace elements that are relevant for your code. This can be helpful when
debugging large exception stack traces. This feature is inspired by the
pretty-printing of stack traces in [utest](https://github.com/lihaoyi/utest).

Check out the
[writing assertions guide](https://scalameta.org/munit/docs/assertions.html) to
learn more how to write assertions with helpful error messages.

## Tooling integrations

The tooling side of a testing library is just as important as the library APIs.
MUnit is implemented as a JUnit runner, which means that any tool that knows how
to run a JUnit test knows how to run MUnit tests.
The tooling side of a testing library is equally important as the library APIs.
MUnit is implemented as a JUnit runner, which means that any existing tool that
knows how to run a JUnit test suite knows how to run MUnit test suites.

For example, IntelliJ already detects MUnit test suites even if IntelliJ has no
custom logic to support MUnit.

![Demo showing IntelliJ running MUnit tests](https://camo.githubusercontent.com/2965bd83df7b98dbc2734815c5bcbe3e784f6242/68747470733a2f2f692e696d6775722e636f6d2f6f4141325a65512e706e67)

Likewise, build tools such as Gradle and Pants can integrate with MUnit using
existing JUnit integrations.
their existing JUnit integrations.

## Insightful test reports

Expand All @@ -234,16 +235,16 @@ to be legitimately flaky.

The Metals codebase has ~1.5k test cases, some which run against up to seven
different Scala compiler versions. It's not ideal that some test cases fail
non-deterministically but it's normal that it happens as the project evolves.
While there is no silver bullet for avoiding flaky test failures, having data
about how frequently a test fails is at least a starting point to begin
addressing the problem.
non-deterministically but it's normal that it happens as the project grows and
we support more build tools, Scala versions and features. While there is no
silver bullet for avoiding flaky test failures, having data about how frequently
a test fails is at least a starting point to begin addressing the problem.

Check out the
[generating test reports guide](https://scalameta.org/munit/docs/reports.html)
to learn how to configure your build to upload test reports to Google Cloud
using the MUnit sbt plugin. The plugin is implemented as an sbt `testsListener`
so it works in theory with any testing library (including ScalaTest, utest, ...)
using the MUnit sbt plugin. The plugin is implemented as an sbt `TestsListener`
so should work with any testing library (including ScalaTest, utest, ...)
although it has so far only been tested against MUnit.

## Credits
Expand Down

0 comments on commit a4ba585

Please sign in to comment.