Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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)