https://kotlinlang.org logo
Join Slack
Channels
Powered by
# minutest
  • r
    Copy code
    fun loginUser() = before {
  // do login things that may throw exceptions
}
  • c
    yeah. i think thats a reason to add before to failfast
  • c
    right. but then loginUser() is not a normal api call thats tested and instead a test utility method
  • c
    and you still need some kind of before support
  • r
    right, and you have the problem of educating users to write things that way, which is not intuitive to people newer to Kotlin
  • d
    The problem comes down to wanting the computer to know which statements inside our context blocks should be lazy or not. We need eager for, for example, loops to define lots of tests, and lazy for things that should only happen when we actually execute.
  • d
    I went with a model of blocks to define the later, because it’s easy, at the expense of having to have a type for the fixture.
  • d
    I then made a virtue of the fixture type by claiming (I think rightly) that it aids test composition, and it certainly helps me think about where and when effects occur.
  • d
    Other models are available though - this is just the one that makes sense to me
  • d
    I vacillate between making all effects in the context, and having tests that just assert; and having context set up common state with tests that then modify it and then assert
  • d
    You can look at this as setting up all of the system in Given, no When, just Then; vs a common Given and then multiple When Thens
  • d
    It’s telling that Given When Then systems tend to have no nested contexts, and nested context systems tend to have no When Thens
  • c
    when the fixture creation throws do you consider all the tests in the context and all of its subcontexts as failed?
  • c
    in failfast i will report a failing context as a test failure (pretend the context is a single test)
  • c
    actually when writing example code for subtests i thought that context and a test could be the same.
  • d
    From JUnit’s perspective, the fixture creation in the current and all parent contexts is part of the test itself.
  • c
    ok so they automatically all fail.
  • d
    Yes, as there will be an invocation of all the code for each test
  • d
    I’ve just released v2.0.0-alpha to bintray! Please have play, and let me know if the upgrade path is smoothish:
    Copy code
    ## 2.0.0-alpha

### DSL changes (old methods deprecated)

* before -> beforeEach
* after -> afterEach
* fixture -> given
* modifyFixture -> beforeEach
* deriveFixture -> given_

### DSL changes (old methods renamed)

* test and test_ no longer take a TestDescriptor parameter to their block, but do supply the fixture as both receiver and parameter. The old versions are available as old_test and old_test_.

### Other DSL changes

DSL functions with TestDescriptors are available in an Instrumented object.

### Test Engine

The JUnit 5 (not Jupiter) test engine is now working well.
It should find methods or top-level functions annotated @Testable, and you can even point to methods in IntelliJ and run them.
Add this to Gradle to enable

tasks.withType<Test> {
    useJUnitPlatform {
        includeEngines(
            "junit-jupiter", 
            "minutest" <-- This
        )
    }

### Parallel Test Running

Run tests in each root context in parallel by setting a system property dev.minutest.parallel.
Parallel running isn't on by default yet, but seems solid.
  • d
    I haven’t created a branch (trunk-based or die) so the docs GitHub don’t reflect the changes I’m afraid.
  • d
    But now I have, so you can see the new docs at https://github.com/dmcg/minutest/tree/v2
  • d
    I’ve published a 2.0 release candidate on Maven Central under dev.minutest
    👍 1
  • d
    It should be effectively backward compatible, but I hope to get around to publishing a last 1.x release to MC too
  • d
    As well as the 2.0 alpha changes, I propose to rename 
    derivedContext
    to 
    context_
    (with an underscore) to match the rename of 
    deriveFixture
    to 
    given_
  • d
    I’ve published v1.12 to Maven Central as v1.13
  • d
    I'm working my way towards another way of doing Minutest that might integrate better with tooling

    https://youtu.be/PnbV1rVI62I▾

  • d
    Any news on v2 of Minutest? 🙏
  • d
    Ah good question. It’s there in GitHub, but my day job doesn’t need it at the moment, and I was waiting for some feedback on the changes. You can try it out https://central.sonatype.com/artifact/dev.minutest/minutest?smo=true
    👍 1
    d
    • 2
    • 1
  • d
    theres 2.0.0-rc4
  • c
    hey I am thinking about minutest style fixtures (or givens) and I have one problem that puzzles me: what do I do when one field of my fixture depends on a different field of my fixture and I don’t want to make my fixture nullable. heres a failgood test:
    Copy code
    val context = describe {
        val assertionError: AssertionError = AssertionError("failed")
        describe("with a typical valid root context") {
            val ctx =
                RootContext("root context") {
                    test("failed test") { throw assertionError }
                }
            describe("executing all the tests") {
                val contextInfo = assertNotNull(execute(ctx) as? ContextInfo)
                describe("reports failed tests") {
                    val failure =
                        contextInfo.tests.values
                            .awaitAll()
                            .map { it.result }
                            .filterIsInstance<Failure>()
                            .single()
                    it("reports exception for failed tests") {
                        expectThat(failure.failure) {
                            get { stackTraceToString() }
                                .isEqualTo(assertionError.stackTraceToString())
                        }
                    }
                }
    so the fixture is basically the rootcontext (ctx), and the assertionError (because in the test I need to have the assertion error to check that exactly that error is reported as failure) when I try to convert this to a given style (with my own made up test dsl) I have to make the context field nullable and mutable, because I need the given class constructed to reference the exception in my context.
    Copy code
    data class Given(
        val assertionError: java.lang.AssertionError,
        var context: RootContext? = null
    )

    val test =
        context(
            "contextExecutorTest port",
            given = {
                val given = Given(AssertionError("failed"))
                given.context =
                    RootContext("root context") {
                        test("failed test") {
                            throw given.assertionError
                        }
                    }
                given
            }
        )
    is there a better way to do this and avoid making the context nullable?
    • 1
    • 1