[test-sbt] More uniformity. #10120
Open
[test-sbt] More uniformity. #10120
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
61d736b to
246ce39
Compare
e0332e7 to
a908303
Compare
2 tasks
b96fecc to
d4b4e6e
Compare
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 ;)
d4b4e6e to
3df9da4
Compare
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.
Currently, code implementing
sbt.testing.Frameworkfor 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.Frameworkruns on do have inherent differences: tests running on Scala.js and Scala Native are running outside of the 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.Frameworkdiverged from one another is the machinery to test them: only JVM implementation is currently testable. With this pull request,sbt.testing.Frameworktests run on all the backends.Another divergence is in the storage of test summaries: JVM uses
AtomicReference[Vector], Scala.js usesBuffer, Scala Native usesConcurrentLinkedQueue; 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, 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
is on target: this was not trivial ;)