typelevel / typelevel/munit-cats-effect

ResourceSuiteLocalFixture is allocated after suite's beforeAll()

Open
#234 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Scala
Stars
159
Forks
40
Avg merge
1d 21h
Merged PRs (30d)
6

Description

The following code

import cats.effect.IO
import cats.effect.kernel.Resource
import munit.CatsEffectSuite


class TestWsResource extends CatsEffectSuite {

  val d = ResourceSuiteLocalFixture(
    "Double resource",
    Resource.make(IO.println("Allocating resource") >> IO(4.0))(d => IO.println(s"Releasing resource: $d"))
  )

  override val munitFixtures = List(d)

  test("resource") {
    IO.println(s"Using resource: ${d()}")
  }

  override def beforeAll(): Unit = {
    // println(s"{${d()}")
    println(s"{d()}")
  }

  override def afterAll(): Unit = {
    println(s"After all ${d()}")
  }

}

produces

{{d()}
Allocating resource
Using resource: 4.0
After all 4.0
Releasing resource: 4.0

Changing beforeAll() to

  override def beforeAll(): Unit = {
    println(s"{${d()}")
  }

results in

Allocating resource
Releasing resource: 4.0

Process finished with exit code 255

munit.catseffect.ResourceFixture$FixtureNotInstantiatedException: The fixture `Double resource` was not instantiated. Override `munitFixtures` and include a reference to this fixture.

It looks that suite local resource is allocated after beforeAll and released after afterAll . Is this the desired behavior?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the provided TestWsResource reproduction, focusing on ResourceSuiteLocalFixture, munitFixtures, beforeAll(), and afterAll(). Run it and trace the fixture lifecycle to establish the intended ordering. Done means the ordering is corrected or explicitly documented, with coverage for accessing the fixture from beforeAll and afterAll.

Written by the indexing model from the issue text.

Assessment

Tech stack
scala
Domain
testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.