Baccata on make-prop-implicit-work-with-zio
Baccata on master
Fix Prop implicit instance for … Update the readme (compare)
Baccata on make-prop-implicit-work-with-zio
Fix Prop implicit instance for … Update the readme (compare)
Baccata on remote-cache-ci
Baccata on master
Cached compilation on CI (#256)… (compare)
keynmol on remote-cache-ci
Remove dummy publishing job (compare)
keynmol on remote-cache-ci
try to simplify build (compare)
Also - I've mentioned your message on the issue that Jakub created: https://github.com/disneystreaming/weaver-test/issues/187#issuecomment-789071232
Given the size of your initial integration, it's wholly possible that someone can create a separate artifact (under typelevel or other org) for this exact thing. It's a bit gratuitous for 14 lines, but I understand how convenient it is :)
discipline-munit
integration some time ago
cats.effect.laws.util.TestContext
. Is there a replacement to deal with time-passing (that would be incredibly amazing!) or a workaround to integrate it with TestContext
(I never liked this one)? It seems I cannot override both the ContextShift[IO]
and Timer[IO]
instances because they are marked as final
in BaseIOSuite
.
IO.sleep
sometime in the past? Probably coupled to the internals of IO
I'd believe
With regard to TestContext - there's no direct support because the suites have the default CS/Timer imported, so that all of the IO tasks are executed on the same runtime.
It's down to implicit resolution - I think if you put implicit val tc = TestContext()
in the suite itself, it should shadow the one brought in by extending SimpleIOSuite
?
With regards to IO.sleep - I think that's the same thing as with TestContext's timer - you can build an IO that uses those special CS/Timer and then in the test itself you can run that IO and assert on it I guess.
I'm not that familiar with cats-effect-testkit so not sure what would a better integration look like :)
zio-test
supports dealing with sleeps out of the box, that's a really nice feature
TestContext
is a horrible hack IMO.
Have you discussed at some point support for time-passing tests? I think that would be a great addition and that's what's currently missing in most testing frameworks.
TestContext
is a horrible hack IMO.
@gvolpe:matrix.org not yet, the reason being our primary concern it to cater to I/O heavy integration tests, and that making life easier for unit tests is not so much a priority I'm afraid (that's why we parallelise by default, which might partially explain why execution times wouldn't be great if you're using weaver for unit-testing and haven't set parallelism to 1). Moreover, the incoming churn in the ecosystem makes the incorporation of new features tricky
TestContext
allows us to do (e.g. ec.tick(5.seconds)
to manually forward time) but in a purely functional way, not via unsafeToFuture
or so :)
@ybasket, hey, thanks for the praise :)
regarding Intellij, we're currently hoping to remove the plugin altogether in favour of a Junit runner that Intellij would pick up natively (maintaining the plugin is a PITA for various reasons, and bumping the max version might not "just work"). I've moved the sources of the intellij plugin
there a few months ago. I'm currently off work but when I come back next week I'll try to find the time to at least write instructions on how to build / install from disk
regarding MUnit, note that you don't have to "jump", the two frameworks can colocate and SBT will know how to use both at the same time :) The two are catering to slightly different usecases : unit testing pure functions with munit is much faster than with weaver because it has less overhead. Weaver is great for testing effectful code and deployed applications
@Baccata Well deserved!
On IntelliJ: That sounds like a good plan with JUnit. If it doesn't work out, there might still be the option to contribute it directly to the IntelliJ Scala plugin – I've done it twice (context-applied & newtypes), they accepted both. My current problem is kinda solved as I was able to compile a working version of the plugin yesterday rather quickly, now I just have to distribute this zip file among my colleagues.
On MUnit: I'm aware of the time penalty weaver has and considered having both, but our codebases are small enough to ignore a few milliseconds and avoid the (mental) overhead of having both. But thank you for the hint!
Hey everyone! We've just published new releases of weaver:
If you're using Cats Effect 2, use 0.6.0-M7
If you're using Cats Effect 3, use 0.7.0-M7
The Main thing is finally switching to stable releases of Cats ffect 3 and fs2 3
There's also a small bugfix in global shared resources.
This paves the way to stabilising 0.6.0 and 0.7.0 very soon :) Hope you enjoy and let us know if there are any issues
Hey folks! 👋
May I ask for your opinion about this implementation? https://github.com/gvolpe/pfps-shopping-cart/blob/second-edition/modules/tests/src/main/scala/suite/ResourceSuite.scala
The idea is to primarily support beforeAll
and afterAll
, but also to provide a way to migrate tests that use beforeEach
, afterEach
or beforeAndAfterEach
:)
I'd use guarantee
here instead of <*
(if I read your code correctly the afterAll is guaranteed but not the afterEach)
Just looking at it, I'm not sure whether the afterAll
is sound, it looks like it could be hanging forever (but I assume you've tried it and it doesn't). Is there anything wrong with just :
def afterAll(f: Res => IO[Unit]) = res.flatMap(r => Resource.make(IO.unit)(_ => f(res)))
?
guarantee
, I forgot that the expected IO[Expectations]
can also raise errors
afterAll
in a test suite? Not very clear to me by looking at it
beforeAll
, no? As the second resource would be evaluated - and f(res)
would run - before any of the tests are executed.
Though, if I understand correctly, that would be more a beforeAll, no?
No the f
is called in the finaliser of the inner resource
hello at gvolpe dot com
mmm, maybe I'm doing something wrong, but after upgrading to 0.6.0 I can't import SimpleIOSuite
anymore:
object SimpleIOSuite is not a member of package weaver
[error] import weaver.SimpleIOSuite
It seems the package object that defines those aliases https://github.com/disneystreaming/weaver-test/blob/master/modules/core/cats/src/weaver/package.scala is not in weaver-core_2.13-0.6.0.jar
anymore
Do I need to add some new dependency?