Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Ólafur Páll Geirsson
    @olafurpg
    It's probably possible to implement a buffering logger outside of the sbt system that flushes the output after each test suite completes
    You may need to implement the same logic twice, once in Scala and once in Java
    not 100% sure if that's necessary here, but some internals are duplicate to support Scala.js and Native
    Jens Halm
    @jenshalm
    Oh, that sounds fun. :-) Thanks for the pointers. I'll first check how quickly I can make sense of the implementation (I don't know much about JUnit or sbt's test framework, so it might take a while).
    after every test suite has finished running
    Jens Halm
    @jenshalm
    Isn't it more complicated though? Wouldn't the buffering need to happen with one buffer per suite in case of parallel execution?
    Jens Halm
    @jenshalm
    I only briefly skimmed over the code in the two classes, I might take a closer look over the weekend. But I did not spot any easy opportunity to add this behaviour, as EventDispatcher only seems to have a way of detecting the first test of the suite and not the last.
    Another little thing I noticed (although I might be missing something) is that RichLogger. popCurrentTestClassName() might be prone to race conditions in parallel execution.
    Ólafur Páll Geirsson
    @olafurpg

    is that RichLogger. popCurrentTestClassName() might be prone to race conditions in parallel execution.

    Good catch. That field can probably be removed because it's not really used

    That code was originally forked from junit-interface, which had a different way to highlight relevant stack trace elements
    I think you can buffer log messages in something like private final ConcurrentHashMap<Description, ConcurrentLinkedDeque<String>> buffers = new ConcurrentHashMap<>();
    Ólafur Páll Geirsson
    @olafurpg
    And then override the testSuiteFinished hook to flush logs
    System.out is already synchronized so everything should work in a concurrent setting as long as you use a call println() or write() once per test suite
    Ólafur Páll Geirsson
    @olafurpg
    feel free to commandeer that branch and open a PR
    I'm open to enabling this by default
    Jens Halm
    @jenshalm

    Ah great, I certainly would have needed much longer. I'll play with this on the weekend.

    My main hurdle for quickly understanding the fairly simple code of RichLogger or EventDispatcher was merely the scoping, meaning how many instance of those exists, whether they are global, per suite, per test or some other scope. Which determines how they need to be synchronized (if at all). The use of synchronization in EventDispatcher suggests it is not "per suite", however it is only ever instantiated in JUnitTask.execute which kind of felt to me like it is scoped to a single suite.

    Jens Halm
    @jenshalm
    @olafurpg did a quick check on my project and it seems to work great (apart from a minor issue of reverse order which is trivial to fix). I'll turn this into a PR over the weekend and also add some docs (I'd suggest to the existing section "Run tests in parallel" as it matters the most in that context).
    Jens Halm
    @jenshalm
    btw. I think my confusion was justified. :-) Out of curiosity I added a lot of low-level logging to EventDispatcher and the result is: 1) I get one instance per suite, 2) the reportedSuites property never has more than one item in it (which is always the suite the dispatcher belongs to), 3) even with parallel execution each dispatcher is always invoked by the same thread. It's not super-important performance-wise, but from this observation it seems that some of the synchronization in EventDispatcher and RichLogger may not be necessary.
    Ólafur Páll Geirsson
    @olafurpg
    Interesting
    I only did the minimal changes to the original junit-interface implementation to tweak the error message reporting to my preferences
    Looks like JUnitReporter is the Scala-equiavalent for EventDispatcher (they should probably be named the same)
    I don't think we need to tweak the Scala implementation, it's only used for Scala.js and Native
    Jens Halm
    @jenshalm
    Yes, I'll look into general improvements after I did the PR for buffered logging. I think EventDispatcher and RichLogger should be cleaned up. They are implemented for multi-suite, multi-thread use, but they are A) not used in that way in practice, B) would be buggy if used that way as there is a race condition.
    Jens Halm
    @jenshalm

    @olafurpg I did the PR for buffered logging here: scalameta/munit#397 - I did not make this option the default yet, that's kind of your call, happy to add that change if you want. I'm also open to duplicate the work for JS and Native, maybe in a separate PR.

    I also opened an issue for several concurrency issues I found in the junit-interface module (more than the ones I already mentioned here): scalameta/munit#399. It's easy to fix those in the way suggested in the ticket, but I did not start yet, as I wanted to check whether you have any objections. The work is also best done after buffered logging is merged.

    Ross A. Baker
    @rossabaker:matrix.org
    [m]
    I don't have a minimization yet, but http4s has lost its test output since upgrading to 0.7.28. I get it back if I turn off the buffered logging.
    Ross A. Baker
    @rossabaker:matrix.org
    [m]
    bblfish
    @bblfish:matrix.org
    [m]
    is there an example of an munit project for scalajs on Scala 3 ? (I am on 3.1.0-RC2 in case that matters).
    bblfish
    @bblfish:matrix.org
    [m]
    I have tests in one project that I am trying to get to run in another project. It works with Java projects, but I don't seem to have luck with the scalajs ones. I think I followed the doc
    bblfish
    @bblfish:matrix.org
    [m]
    I may have found the problem, in which case there could soon be such a project.
    bblfish
    @bblfish:matrix.org
    [m]
    ok, got it
    Pathikrit Bhowmick
    @pathikrit

    I have a multi module with munit like:

    lazy val commonSettings = Seq(
      scalaVersion := "2.13.7",
      scalacOptions ++= Seq("-unchecked", "-deprecation", "-feature"),
      libraryDependencies ++= Seq(Dependencies.munit),
      testFrameworks += new TestFramework("munit.Framework")
    )
    
    lazy val framework = project.in(file("framework"))
      .settings(commonSettings: _*)
      .enablePlugins(ScalaJSPlugin)
      .settings(libraryDependencies ++= Seq(Dependencies.cask) ++ Dependencies.scalaJs.value)

    And, I have a test in framework/src/test/scala/SomeTest.scala. But when I do sbt> framework/test it does not pick up the tests but the compilation does (if I make a syntax error in the SomeTest.scala) it picks up the compile error. What am I doing wrong?

    Ólafur Páll Geirsson
    @olafurpg
    @pathikrit im not sure what’s wrong, the settings look OK. In recent sbt versions you don’t need to configure testFrameworks
    Is the test suite in a package?
    what happens if you move SomeTest.scala to a subdirectory with an explicit package name?
    Pathikrit Bhowmick
    @pathikrit
    image.png
    Yes it is in a package. In fact IntelliJ detects it as test and I can run it from IDEA ...
    image.png
    But doing test does not pick it up ...
    Ólafur Páll Geirsson
    @olafurpg
    @pathikrit are you using %%%? It looks like this is a Scala.js project and you need to use %%% to pick up the JS version of MUnit instead of the JVM one
    It's a shame that it's a is a silent failure to use %% instead of %%% but that's outside the control of MUnit
    Pathikrit Bhowmick
    @pathikrit
    Yup %%% solved it! I did not realize that even if my tests were not scala.js related it won't get picked up
    msosnicki
    @msosnicki
    Hi! Is there a way to nest tests using munit? I have found this PR scalameta/munit#133 but it got closed because it was potentially breaking other features (filtering etc). It mentions a solution build on top of JUnit nested descriptions but not sure what is the state of it?
    Ólafur Páll Geirsson
    @olafurpg
    @msosnicki there's no way to nest tests with MUnit, you're basically limited to a single flat list of tests within a test suite. You can split the test suite into two suites as a workaround
    I have a WIP branch upgrading to JUnit 5, which would make it easier to implement nested tests
    msosnicki
    @msosnicki
    @olafurpg thanks a lot! Looking forward to that feature (even without it it's great to use, love the simplicity)
    Ólafur Páll Geirsson
    @olafurpg
    I'm keen on getting the JUnit 5 upgrade ready at some point, it cleans up a lot of things!
    Sean Cheatham
    @SeanCheatham

    Hi folks! I'm working on transitioning some of our unit tests from ScalaTest to MUnit out of a need to support Async Generator-driven checks. Similar to Pathikrit's issue above, I'm unable to run any MUnit suites from SBT using test. IntelliJ is able to properly discover and run the unit tests, but SBT (v1.6.2) does not detect any tests and outputs No tests were executed.. In my case, I'm not using ScalaJS or PortableScala. My submodule includes this:

     .settings(
        testFrameworks += TestFrameworks.MUnit,
        libraryDependencies ++= Seq(
          "org.scalameta" %% "munit"                   % "0.7.29" % Test,
          "org.scalameta" %% "munit-scalacheck"        % "0.7.29" % Test,
          "org.typelevel" %% "munit-cats-effect-3"     % "1.0.7"  % Test,
          "org.typelevel" %% "scalacheck-effect-munit" % "1.0.4"  % Test
        )
      )

    Has anyone else experienced this issue?

    3 replies