test-sbt: [bug] match tests on both short and prefixed names. #9756
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
2d9d681 to
7c60c5c
Compare
d39a623 to
f9d3b6f
Compare
kyri-petrou
reviewed
Apr 26, 2025
| @@ -112,17 +112,20 @@ final case class Spec[-R, +E](caseValue: SpecCase[R, E, Spec[R, E]]) extends Spe | |||
| * spec. If no labels satisfy the specified predicate then returns `Some` with | |||
| * an empty suite if this is a suite or `None` otherwise. | |||
| */ | |||
| final def filterLabels(f: String => Boolean)(implicit trace: Trace): Option[Spec[R, E]] = | |||
| final def filterLabels(f: String => Boolean, prefix: String = "", accumulatePrefix: Boolean = true)(implicit | |||
There was a problem hiding this comment.
This isn't binary compatible (which is why CI is failing). You'll have to introduce a new method called filterLabels with the additional arguments, and proxy to it from the original method. i.e.,:
final def filterLabels(f: String => Boolean)(implicit trace: Trace): Option[Spec[R, E]] =
filterLabels(f, "")
final def filterLabels(f: String => Boolean, prefix: String, accumulatePrefix: Boolean = true)(implicit trace: Trace): Option[Spec[R, E]] = {
// implementation goes here
}There was a problem hiding this comment.
You'll have to introduce a new method ...
Thank you for the clue!!
Done.
568aab0 to
a514126
Compare
|
@kyri-petrou any thoughts? Thanks! |
Thank you, @hearnadam! |
|
@kyri-petrou @hearnadam Is there anything I need to do for this to get merged? |
If a test is defined as `suite("suite")(test("test"){})`
it seems reasonable that we should be able to ask for it to be executed
by either its short name "test" or by its full name "suite - test".
This *can* be achieved by stripping the suite prefix "suite -" from the names from the selectors.
However, this approach breaks down in the presence of nested suites;
e.g. if a test is defined as `suite("outer")(suite("inner)(test("test"){}))`,
when the outer suite is run:
- selector "test" still executes the test - as it should;
- selector "inner - test" does not execute the test (wrong prefix gets stipped) - but should;
- selector "outer - inner - test" does not execute the test (inner prefix does not get stripped) - but should;
- selector "outer - test" does execute the test - but shouldn't, since test with such a full name does not exist.
To make this work correctly, `Spec.filterLabels()` has to be adjusted to keep track of the accumulated
suite prefix and match the search terms against the full names.
Once that is done, we do not need to strip anything here;
in fact, we do not even need know what the label of the spec is.
328208a to
d5c9101
Compare
hearnadam
approved these changes
Jun 16, 2025
|
@dubinsky good to merge? |
Yes. Thanks you! |
hearnadam
added a commit
that referenced
this pull request
Jun 16, 2025
/closes #9756 `exitCode` operator is dangerous as it swallows all errors. Since this is no longer necessary for creating a ZIOApp, it should no longer be used.
hearnadam
added a commit
that referenced
this pull request
Jun 16, 2025
/closes #9756 `exitCode` operator is dangerous as it swallows all errors. Since this is no longer necessary for creating a ZIOApp, it should no longer be used.
hearnadam
added a commit
that referenced
this pull request
Jun 21, 2025
/closes #9756 `exitCode` operator is dangerous as it swallows all errors. Since this is no longer necessary for creating a ZIOApp, it should no longer be used.
hearnadam
added a commit
that referenced
this pull request
Jun 21, 2025
/closes #9756 `exitCode` operator is dangerous as it swallows all errors. Since this is no longer necessary for creating a ZIOApp, it should no longer be used.
hearnadam
added a commit
that referenced
this pull request
Jun 26, 2025
* Deprecated `ZIO#exitCode` /closes #9756 `exitCode` operator is dangerous as it swallows all errors. Since this is no longer necessary for creating a ZIOApp, it should no longer be used. * fix brittle test
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 19, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on do have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. There remain a couple of code divergencies: - the way runtime layer is constructed is different for JVM and non-JVM backends; - the method used to actually run the Spec is different for JVM and non-JVM backends; I am trying to discern if those differences are actually warranted - or subject to further simplification and unification. @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 19, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on do have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. There remain a couple of code divergencies: - the way runtime layer is constructed is different for JVM and non-JVM backends; - the method used to actually run the Spec is different for JVM and non-JVM backends; I am trying to discern if those differences are actually warranted - or subject to further simplification and unification. @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 19, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on do have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. There remain a couple of code divergencies: - the way runtime layer is constructed is different for JVM and non-JVM backends; - the method used to actually run the Spec is different for JVM and non-JVM backends; I am trying to discern if those differences are actually warranted - or subject to further simplification and unification. @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 19, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on do have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. There remain a couple of code divergencies: - the way runtime layer is constructed is different for JVM and non-JVM backends; - the method used to actually run the Spec is different for JVM and non-JVM backends; I am trying to discern if those differences are actually warranted - or subject to further simplification and unification. @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 19, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on do have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. There remain a couple of code divergencies: - the way runtime layer is constructed is different for JVM and non-JVM backends; - the method used to actually run the Spec is different for JVM and non-JVM backends; I am trying to discern if those differences are actually warranted - or subject to further simplification and unification. @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 19, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on do have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. There remain a couple of code divergencies: - the way runtime layer is constructed is different for JVM and non-JVM backends; - the method used to actually run the Spec is different for JVM and non-JVM backends; I am trying to discern if those differences are actually warranted - or subject to further simplification and unification. @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to apply only on JVM; this pull request applies it to all backends (and tests that it does ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 20, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 21, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 21, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
dubinsky
added a commit
to dubinsky/zio
that referenced
this pull request
Aug 21, 2025
Currently, code implementing `sbt.testing.Framework` for JVM, Scala.js and Scala Native suffers from severe code triplication: code doing the same thing is present in three places. This pull request removes this gratuitous redundancy. An unfortunate - and inevitable - consequence of code duplication is code drift: different copies of the code do things differently for no good reason. Backends `sbt.testing.Framework` runs on _do_ have inherent differences: tests running on Scala.js and Scala Native are not running on JVM, and thus their outcomes need to be communicated to the process managing the test run; Scala.js is single-threaded by nature, which affects the way tests have to be run. Code differences not warranted by the inherent differences between the backends seem gratuitous, and this pull request removes some of them. One area where implementations of the `sbt.testing.Framework` diverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request, `sbt.testing.Framework` tests run on all the backends. Another divergence is in the storage of test summaries: JVM uses `AtomicReference[Vector]`, Scala.js uses `Buffer`, Scala Native uses `ConcurrentLinkedQueue`; this pull request unifies summary storage for all backends: `AtomicReference[Vector]` works for all of them. Another divergence is the way test summary is rendered: counts of tests executed, ignored, or failed are included in the summary on JVM but not on Scala.js or Scala Native; setting test renderer to IntelliJ in the test arguments is honored only on JVM. This pull request makes test summary uniform across the backends. Another divergence is: currently, signal handlers are installed only on JVM. This pull request installs them on all backends. Another divergence affects a recent [enhancement](zio#9756), which turned out to be effective only on JVM; this pull request applies it to all backends (and tests that it works ;)). @kyri-petrou, your [remark](zio#9629 (comment)) > I gave it a go at this (basically trying to unify the JVM / JS / Native implementations so that we can reuse the existing event test suites that exist for the JVM, but it doesn't seem possible. > ... writing a full test suite from scratch (which frankly it's going to be extremely time consuming) is on target: this was not trivial ;)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a test is defined as
suite("suite")(test("test"){}), it seems reasonable that we should be able to ask for it to be executed by either its short nametestor by its full namesuite - test.When outer suite is run via
sbt.testingand tests to run specified usingsbt.testing.Test[Wildcard]Selector, this can be achieved by stripping the suite prefix "suite -" from the names in theSelectors. However, this approach breaks down in the presence of nested suites; e.g. if a test is defined assuite("outer")(suite("inner")(test("test"){})), when the outer suite is run:testdoes executes the test - as it should;outer - testdoes execute the test (prefix gets wrongly stripped) - but should not, since test with such a full name does not exist;inner - testdoes not execute the test (wrong prefix gets stripped) - but should;outer - inner - testdoes not execute the test (inner prefix does not get stripped) - but should.When outer suite is run directly and tests to run specified using search terms (
-t):inner - testdoes not execute the test - but should;outer - inner - testdoes not execute the test - but should.To make this work correctly, an overload of
Spec.filterLabels()is introduced that keep track of the accumulated suite prefix and matches the search terms against prefixed names. This overload is used inFilteredSpec.