<@UFGCACPE0> Is there such a thing as a prepared v...
# opensavvy
d
@CLOVIS Is there such a thing as a prepared val that can take parameters when called? Also is there any way to disable a whole PreparedSpec (it's a bit heavy to run every time...)
My use case:
Copy code
class PopularGroupTypeSpec : PreparedSpec({
    val runAndAssert: suspend (ListQuery<CollectionItemId>, expected: String) -> Unit = { query, expected ->
        expectThat(query.dryRunOrThrow()).isSqlEqualTo(expected)
    }

    popularGroupSuite(runAndAssert)
})
I want to have a spec to run against a real db too... but disabled unless I enable it... so that runAndAssert would need access to Prepareds... even though the basic version (the one I posted above) is only testing against the sqls themselves so it doesn't have any deps.
c
a prepared val that can take parameters when called?
How do you envision this? The point of Prepared is that the value is "bound" to the test and cannot change. Which case do you want? If you want a bunch of values that are each bound, I guess you could to that with a
Map<YourThing, Prepared<…>>
Also is there any way to disable a whole PreparedSpec
Maybe something like this works? 👀
Copy code
class Foo : PreparedSpec({
    return@PreparedSpec // stop it

    …
})
else, you can
Copy code
class Foo : PreparedSpec({

    suite("All the tests", Ignored) {
        // …all your tests…
    }
})
If you want, you can create an issue for configuring the tests at the spec level, and I'll add
Copy code
class Foo : PreparedSpec(Ignored, {
    // …
})
d
I really wanted to provide different implementations to that runAndAssert lambda but the one using real dbs would need to be dependent on a Prepared db connection... I guess I could always make runAndAssert's receiver into TestDsl and just use the db() prepared straight in the function, but I'm really looking for suggestions or maybe a better way that I'm thinking of? As for disabling tests, I could maybe just have a suite with Ignored for the db tests, and another one for the regular, faster tests, thanks!
c
I'm not sure I understand what
runAndAssert
is for. Typically, the way to reuse test suites for multiple implementations is to write a suite that accepts a
Prepared<TheThingToTest>
d
Here it's the same thing to test, just a different way to run and assert... each test has a Query object from #C03JF82SDHA, and I can either dryRun the query and test the sql, or run the query with testcontainers to ensure that it runs ok against the db's schema...
c
Ah, interesting Yeah, I'd make that a
suspend TestDsl.() -> Unit
lambda, this way it can use prepared values
👍🏼 1