-
Notifications
You must be signed in to change notification settings - Fork 74
Conversation
@@ -41,7 +41,8 @@ resolvers ++= Seq( | |||
) | |||
|
|||
libraryDependencies ++= Seq( | |||
"org.scalatest" %% "scalatest" % "3.0.5" | |||
"org.scalatest" %% "scalatest" % "3.0.5", | |||
"com.lihaoyi" %% "utest" % "0.7.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
) | ||
|
||
testFrameworks += new TestFramework("utest.runner.Framework") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional line to let sbt test
invoke utest
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, will merge if there are no further objections.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I don't see the same degree of integration with utest compared with the Scalatest environment interface? The main reason the ScalatestTester exists is to provide better integration with ScalaTest to a degree that isn't possible if a failed tester2 expect was to just throw a generic exception - the main example is that a failed expect actually propagates to a Scalatest failure instead of just dumping a stack trace. Is there an analog to utest? If not, would it make more sense to just use RawTester (perhaps with a cleaner API) instead? Note - I'm not too familiar with utest, I only did a cursory glance over the documentation. There may be other benefits to having a utest specific testers2 environment - though that would need to be balanced with the additional code that needs to be maintained as well as requiring additional dependencies.
Yes, |
1. ignore topFileName, use utestFormatter directly highlight the error line. 2. use utest.testPath provide test name like scalatest does in scalaTestContext.
Unfortunately, there doesn't appear to be a Scala 2.11 version of utest 07.1, which is causing current CI builds to fail:
I'll file an issue on https://github.com/lihaoyi/utest |
Oh sorry. I didn’t remember we have to support 2.11, I’ll try to pr that later. |
I just found that they
in |
(cherry picked from commit da4f226)
* Implement ChiselUtestTester for utest (#76) (cherry picked from commit da4f226) * Use latest utest; fix issue utest#211 (#77) * Use latest utest; fix issue utest#211 * Fix compatibility problem for 2.11 and 2.12 (cherry picked from commit 652a248) * Add valid io driver (#63) * Adds an ValidDriver interface similar to Decoupled * Cleanup imports in ValidQueueTest * Adds an ValidDriver interface similar to Decoupled Adds tests for this construct * Round 2 of ValidDriver support - change name to validSourceKey - remove enqueue, only supports enqueueNow - change how enqueueNow works internally - Simplify testing of Valid - make DUT have delay and typeGen - eliminate ValidQueue, just use Pipe instead - add example that shows how to enqueue multiple bundles at the same cycle * Valid interface updates - Add comment on valid's expectPeek saying it does not advance time - got rid of errant comment mentioning stall - used dequeueSeq for pass through elements test - renamed test with expectInvalid and added loops - added parens to getSourceClock calls * - removed wrongly changed entry in .gitignore - removed duplicated code in ValidQueueTest (cherry picked from commit 72cb844) * Fix toolchain so treadle supports boringutils (#79) * Fix toolchain so treadle supports boringutils - Add the low firrtl compiler to TreadleExecutive - Send hint to treadle so it knows compiled form - Fix backward compatibility with Driver - Check compiler type to help figure out the backend - Backward compatibility only supported for treadle and verilator - Add boringutils test - Backward compatibilty requires compile workaround - Can we just eliminate Driver compatibility mode here??? - Fixed CopyVpiFiles - looks like this might fail if early file was there but a late one wasn't - this code came from chisel-testers - Fix top level test names - behavior of "Testers2 with Vcs" - behavior of "Testers2 with Verilator" - Shortened VCS to just see if a simple circuit will build and simulate. - in long run we still need mechanism to run an arbitrary test with arbitrary backend * - Made associations between compiler and backend in compat mode explicit - In BoreTest - removed unused code. - In MixedVec - Renamed to VecPokeExpectTest - tested all addresses - removed bundle (cherry picked from commit dd6d083) * Fix external links in README (#84) (cherry picked from commit b6ea7e9) * Merge pull request #85 from ucb-bar/peekBundle Support Bundle literal peek (cherry picked from commit ea5e81f) * support enqueue/dequeue of IrrevocableIO (#90) * support enqueue/dequeue of IrrevocableIO Signed-off-by: shuyun <[email protected]> * fix per commit Signed-off-by: shuyun <[email protected]> (cherry picked from commit 6767faa) * Fix missing Scaladoc parenthesis (#92) Signed-off-by: Schuyler Eldridge <[email protected]> (cherry picked from commit 7e4ef7f) * Fix README links (#109) (cherry picked from commit 2b6cae0) * Re-add -DwriteVcd=1 feature (#110) (cherry picked from commit 2f1cbae) * gitignore: add Visual Studio Code folders (#100) (cherry picked from commit d9d2a7a) * Bump minor version Co-authored-by: Sequencer <[email protected]> Co-authored-by: Chick Markley <[email protected]> Co-authored-by: edwardcwang <[email protected]> Co-authored-by: Richard Lin <[email protected]> Co-authored-by: ShuyunJia <[email protected]> Co-authored-by: Schuyler Eldridge <[email protected]> Co-authored-by: Øyvind Harboe <[email protected]>
No description provided.