lihaoyi/utest

A tiny, portable testing library for Scala

Tobias Roeser

@lefou

I always hit the test - method should only be used directly inside a Tests{} macro error.

Tobias Roeser

@lefou

@lihaoyi could you comment?

Li Haoyi

@lihaoyi

@lefou utest doesnt have good built in support for that kind of thing. If your matrix is small, you can use an abstract test suite that multiple suites inherit from. Or you could move the test logic into a helper and spell out all the permutations as separate tests. Neither are ideal, but it is what it is

Tobias Roeser

@lefou

Got it, thank you

Tobias Roeser

@lefou

Does uTest support pending / skipping tests or the concept of assumptions as a precondition to run/skip a test?

Li Haoyi

@lihaoyi

not explicitly as features; we've been commenting our tests or wrapping their bodies in if statements as workarounds

Tobias Roeser

@lefou

Ok. But this has the downside, that skipped tests are not counted and won't appear in any reports/statistics. Other frameworks have this, e.g. Junit, Testng, Scalatest, ...

Henry Story

@bblfish

IS there are release for Scala3 RC1 in the works?

jodersky

@jodersky

check out the pull requests ;)

Iurii Malchenko

@yurique

looks like there’s a 0.7.7 released for Scala3 RC1, but not for Scala.js – am I right and is this as intended? :)

jodersky

@jodersky

at the time I submitted the PR I did not know that ScalaJS for Scala 3-RC1 was already available

Iurii Malchenko

@yurique

got you!

is it possible to release it “after the fact”? :) (or should we wait for the next version?)
utest is the only testing lib I could find that can handle async tests in Scala.js, so my Scala 3+.js code hangs untested without it

Iurii Malchenko

@yurique

(I mean, except scalatest, but…)

jodersky

@jodersky

It shouldn't be a problem, releasing "after the fact" is in fact what we did for the RC1 upgrade. I can do it probably tomorrow or early next week

Iurii Malchenko

@yurique

Thank you! :)

jodersky

@jodersky

I don't think Scala JS is published for Scala 3 yet

I tried cross-building with Scala 3.0.0-RC1 and Scala JS 1.5.0, but ran into resolution issues. Plus, looking at https://repo1.maven.org/maven2/org/scala-js/, I cannot see "_3" artifacts available

utest.js[3.0.0-RC1,1.5.0].resolvedIvyDeps 
Resolution failed for 4 modules:
--------------------------------------------
  org.scala-js:scalajs-test-interface_3.0.0-RC1:1.5.0 
        not found: /home/jodersky/.ivy2/local/org.scala-js/scalajs-test-interface_3.0.0-RC1/1.5.0/ivys/ivy.xml
        not found: https://repo1.maven.org/maven2/org/scala-js/scalajs-test-interface_3.0.0-RC1/1.5.0/scalajs-test-interface_3.0.0-RC1-1.5.0.pom
  org.portable-scala:portable-scala-reflect_sjs1_3.0.0-RC1:0.1.1 
        not found: /home/jodersky/.ivy2/local/org.portable-scala/portable-scala-reflect_sjs1_3.0.0-RC1/0.1.1/ivys/ivy.xml
        not found: https://repo1.maven.org/maven2/org/portable-scala/portable-scala-reflect_sjs1_3.0.0-RC1/0.1.1/portable-scala-reflect_sjs1_3.0.0-RC1-0.1.1.pom
  org.scala-js:scalajs-library_3.0.0-RC1:1.5.0 
        not found: /home/jodersky/.ivy2/local/org.scala-js/scalajs-library_3.0.0-RC1/1.5.0/ivys/ivy.xml
        not found: https://repo1.maven.org/maven2/org/scala-js/scalajs-library_3.0.0-RC1/1.5.0/scalajs-library_3.0.0-RC1-1.5.0.pom
  org.scala-lang:scala-reflect:3.0.0-RC1 
        not found: /home/jodersky/.ivy2/local/org.scala-lang/scala-reflect/3.0.0-RC1/ivys/ivy.xml
        not found: https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/3.0.0-RC1/scala-reflect-3.0.0-RC1.pom

Ruslan Shevchenko

@rssh

@jodersky -- dotty include scalajs backend. The scalajs library is published as https://repo1.maven.org/maven2/org/scala-lang/scala3-library_sjs1_3.0.0-RC1/3.0.0-RC1/

Ruslan Shevchenko

@rssh

aga - I see, com-lihaoyi/mill#1103 so in theory scala3 build should be supported out of the box in the next mill.

jodersky

@jodersky

got it. This is what I've tried so far: com-lihaoyi/utest#234

to anyone knowledgeable, feel free to play around with it and see if you can get the correct combination of libraries and mill version for Scala3 and ScalaJS

Lorenzo Gabriele

@lolgab

@yurique @rssh Just published utest 0.7.7 for Scala.js 1 and Scala 3.0.0-RC1

Iurii Malchenko

@yurique

@lolgab awesome! thank you! :)

jodersky

@jodersky

I just published utest 0.7.7 for Scala 3.0.0-RC2. Since we use git-derived versioning in this project, this release is considered "unofficial". Stay tuned for com-lihaoyi/utest#242 (and presumably 0.7.8) for the official release.

nafg

@nafg

What do you mean about git derived making it unofficial?

Lorenzo Gabriele

@lolgab

We now derive the version from the git tags. This 0.7.7 was published manually for 3.0.0-RC2 without tagging a new version and letting the CI do the release. From the user point of view it doesn't change anything.

jodersky

@jodersky

yep, feel free to use it, but just know that there is no source version attached to it. If you'd like something more reproducible, then we'll need to wait for (presumably) 0.7.8

I'll refactor my open PR and move the disabled test to a Scala 2-only source file. That way we should be clear to merge and release 0.7.8 very soon.

Rich

@Rich2

The GitHub repository page still shows 0.6.6 as the latest release.

jodersky

@jodersky

I updated the release, but we also still need to update the readme. Right now it still says 0.7.7

As a general rule to find the latest version however, I would suggest to always look for the latest git tag, or refer to what the readme/website says. GitHub "releases" are a pain to keep up to date manually and tend to get overlooked if the process is not automated

Marc Grue

@marcgrue

This seems to be a simple solution to testing Futures in ScalaJS on the JS side where Await.result cannot be used:

object TestJs extends TestSuite {

  def getJsFuture = Future(org.scalajs.dom.window.location.host)

  val tests = Tests {
    test("ScalaJS future") {
      getJsFuture.flatMap { result =>
        Future(result ==> "localhost")
      }
    }
  }
}

Using flatMap and placing the comparison in a Future did the trick for me (did a SO q/a too).

Are there drawbacks to this approach or a better way to do it?

Marc Grue

@marcgrue

In the readme it says
runBody is a future to support asynchronous testing, which is the only way to test things like Ajax calls in Scala.js - I don't think that is correct, since I'm checking Future results from Ajax calls successfully with the above approach. Am I missing something or could the readme need to be updated?

scalway

@scalway

I assume test(...)(...) already covers that. If result is Future it waits for it (asynchronously of course).
Whole doc about runBody is written for folks that need to somehow wrap theirs tests at runtime.

Sakib Hadžiavdić

@sake92

@marcgrue https://github.com/com-lihaoyi/utest#asynchronous-tests section shows that you can return a Future and it will work fine

Marc Grue

@marcgrue

@sake92 Damn, you're right. Don't know how I missed that. And thanks, @scalway for clarifying the runBodypart which confused me. Sorry for the spam, guys.

Luís Campos

@LLCampos

Hello everyone :) I created a repo with a summary of the Scala testing libraries ecosystem: https://github.com/LLCampos/state-of-the-art-scala-testing/ Should I add/change anything regarding utest?

Marc Grue

@marcgrue

It seems that only the last of multiple futures in a single test is considered:

test("pass") {
  Future(1 ==> 2)
  Future(1 ==> 1)
}

test("fail") {
  Future(1 ==> 1)
  Future(1 ==> 2)
}

test("last completing still doesn't fail") {
  Future {
    setTimeout(100) {
      1 ==> 2
    }
  }
  Future(1 ==> 1)
}

Is there a way to test multiple futures in each test or am I doing something wrong?

Lorenzo Gabriele

@lolgab

@marcgrue You need to combine them into one and return it...
Because the library will use the returned value to wait on it.
I usually use for comprehension to make my life a bit easier.
Something like:

test("test 1") {
  for {
    _ <- Future(1 ==> 2)
    _ <- Future(1 ==> 1)
  } yield ()
}

test("test 2") {
  for {
    _ <- Future(1 ==> 1)
    _ <- Future(1 ==> 2)
  } yield ()
}

test("test 3") {
  for {
    _ <- Future {
      setTimeout(100) {
        1 ==> 2
      }
    }
    _ <- Future(1 ==> 1)
  } yield ()
}

Marc Grue

@marcgrue

Ah, ok. Great, thanks for the explanation @lolgab!

Lorenzo Gabriele

@lolgab

Released utest 0.7.10 with support for Scala 3

Marc Grue

@marcgrue

Running tests with multiple futures (as layed out by @lolgab above) works great from sbt. But when I try to run them from IntelliJ, only one or a few complete and the rest are terminated by IntelliJ. Anyone have a clue as to why this happens? Lack of memory? The jvm quitting? I tried various combinations of settings in the test run configuration without luck.

Quafadas

@Quafadas

Is it possible to use uTest in an SBT subproject? I'm trying to construct a scala js / jvm project, but the tests don't appear to be recognised / run by sbt when i do backend/test... could it be because the path is modules/backend/src/test/scala as opposed to the standard src/etc/etc?

At the very least I don't see any output in the SBT console, it just says "Success"...

Lorenzo Gabriele

@lolgab

Did you add the testFrameworks setting to the crossProject?

Quafadas

@Quafadas

Um.... no ... and actually doing that appears to have made all the difference. That's embarassing.

@lolgab Thankyou very much.

Lorenzo Gabriele

@lolgab

@Quafadas it is a very common mistake, in Mill testFramework is mandatory, so you can hardly get it wrong :)

vito-c

@vito-c

is there a way to have utest display the expected output and actual output when running tests right now I am doing something like this

assert(myfunc(2) == 3)

and on failure it just prints out:

utest.AssertionError: assert(myfunc(2) == 3)

which doesn't give me what the left hand sides actual value is

Lorenzo Gabriele

@lolgab

You can make it print the actual output by assigning it to a value:

val result = myfunc(2)
assert(result == 3)

Where communities thrive

People

Repo info

Activity