also because of the naming pattern i have to load only a subset of the classfiles which also speeds up test discovery. (but probably its not a big deal)

i guess i could make the `@Test`annotatation mandatory, all failgood tests that i know of use it anyway

Personally I prefer the clarity of intent that using an annotation affords. Just my opinion tho.

btw i pushed a big docs update yesterday, and would love some feedback on it: https://github.com/failgood/failgood#readme

trying to write docs made me realize that the test discovery part is not yet great.

btw i also use kotlin-power-assert for tests now with a combination of `assertNotNull()`for navigation and

assert

for the actual assertion like this:

val failedContext = assertNotNull(suiteResult.failedRootContexts.singleOrNull())
assert(failedContext.context.name == "root")

the only thing thats missing is soft asserts

what’s the best way to mark pending tests? I think it would be great to have pending tests that fail on ci, because its something that you need to do before merging your pr. but there also need to be ignored tests that you don’t care about. should i just introduce an ignored keyword in addition to pending?

ok in main tests are now found via

@Test

annotation, and file name or class name no longer matters.

oh hello there

I’m now working on an idea plugin.

the main branch is now feature complete for the 0.8 release. the main new feature is an option to turn off test isolation for a sub contexts, which is great if you want to stick to 1 assertion per test. currently undocumented but feel free to try it out. https://github.com/failgood/failgood/blob/main/failgood/jvm/test/failgood/functional/SubContextIsolationTest.kt#L16

sequential test steps api draft: https://github.com/failgood/failgood/pull/124 cc @Mervyn McCreight

🖐️

what do people here think about the new Ignore API? https://github.com/failgood/failgood/pull/139

what is now in the main branch will be released as 0.8.2 sometime this week.

really interesting article about test dependencies: https://thoughtbot.com/blog/the-self-contained-test I always try to find a middle ground where I just put the “boring” dependencies into the context, and everything that is really needed is then done in the test. for example If I need a user object I will have a generic user instance in the test context, and then in each test i set the fields that really matter for that test via the copy function. Maybe something to blog about…

I often use the copy function in exactly that way — to customize a “generic” data class instance that’s a class level variable for particular conditions in the test method

I started a discussion how to do collection asserts in a power assert style api, please chime in if you have ideas: https://github.com/bnorm/kotlin-power-assert/discussions/74

that looks nice: https://github.com/danger/kotlin

does anyone here have an opinion on this? https://github.com/failgood/failgood/issues/201 just comment on the ticket with ideas.

the git main branch now contains an optional new junit engine. see the changelog on how to try it out

coming soon: the failgood idea plugin to run single tests or contexts from idea.

https://github.com/christophsturm/failgood-idea you can build it yourself if you want to try it out. in some days it will probably appear in the idea plugin marketplace

with the addon there is no need to additionally alter any settings in idea anymore, right?

I’m not sure. the only thing the plugin currently does is create a junit run config that runs a test or context via uniqueid. it will not work when you use gradle to run the tests. if you find out that any config combination does not work just file a github issue and I will take a look. excited to get feedback from other users!

https://github.com/failgood/failgood/releases/tag/0.9.0 happy holidays everybody!

0.9.2 is around the corner and will come with some deprecations: https://github.com/failgood/failgood/pull/372

also failgood 0.9.2 will depend on slf4j and klogging. if thats really bad please speak up.

also I started prototyping a new DSL, https://github.com/failgood/failgood/blob/main/failgood/test/failgood/experiments/andanotherdsl/AnotherDSLExperiment.kt please take a look and tell me what you think.