Is this project dead?

[Fleshgrinder]

I think that Strikt is the best assertion library for Kotlin there is, and we have various issues and pull requests open that don't see any response, as well as no release since more than a year.

I'd also like to offer support in maintaining if the original maintainers currently don't find the time. It would be a real shame for Strikt to vanish. 😢

[MarceloRuiz]

I hope you could get an answer to your offering, because it does not makes much sense to use a project that seems not to be maintained anymore...
Maybe you can contact the owner of this repository via LinkedIn and see if you get an answer that way...

[cvetojevichbojan]

I don't think the project is dead as you can see that there is ongoing work via commits in the last year, its probably just that the owner does not have enough free time to work on the various issues.

@Fleshgrinder i do commend your initiative to jump in as a maintainer, maybe @robfletcher can make this happen and also let us know of the future plans for Strikt?

• +1 for Strikt being the best assertion library for Kotlin 💯

[robfletcher]

Hi, I wanted to jump in here and apologize for recent silence. I lost my job at Netflix last month, so I've been pretty preoccupied with that. As it happens I also lost access to the email address that I used for the Kotlin Slack, so I need to figure out a way to resolve that situation.

I would like to get a release done soon, and again, I apologize for recent inactivity. Thank you all for the pull requests and other contributions.

[Fleshgrinder]

I'm sorry to hear that @robfletcher. I hope you'll find something new or already did. The market isn't the best these days, but there are still plenty of opportunities.

My offer to support still stands. I started using Kotest much more, and it simply can not compare to strikt.

[viluon]

@robfletcher you may consider this an opportunity to move the community from Slack elsewhere, perhaps to a platform with a saner approach to account management and more generous free plans. One option is to set up something like Matrix/Zulip/Discord, another is to favour GitHub discussions over instant messaging.

Just an idea, I'm not in the Slack workspace personally so take this with an appropriate heap of salt 🙂

[robfletcher]

Yeah, I'd be 100% fine with moving to Discord. I use that a lot for other things.

I tried to cut a new release yesterday but ran into an issue with the new auth token policy on oss.sonatype.org. Not sure what I'm doing wrong since I did update the secret the GH action uses to use the tokens. I'll investigate when I get a chance.

[robfletcher]

Also, perfectly happy to bring on a co-maintainer.

[Lysander]

Over one year passed without any further action - hm... imho this is dead :-/

[JotBePunkt]

@robfletcher: is it somehow possible to contribute: I have quite some Ideas to add extension functions for the Assertion Builder e.g. Date / Instant / Duration (Kotlin + Java)

Also I guess soonerr or later the dependencies should be updated etc.

[kdubb]

We love Strikt and still rely on it in a ton of code and it's becoming a liability. I have the utmost respect for @robfletcher and the rest of the contributors and I know full well how shifting priorities can get in the way for years. That being said, it seems like we need to look at forking this since there's no movement on adding contributors

As a testement to the design of the library it is very easy to create extensions for Strikt and forgo anything beside the base library, which is fantastic. That presents two issues, the first of which, and most important, is that the core library isn't being maintained with respect to dependencies. Secondly, that means we have to manage our own published "strikt library" of assertions or, as usually happens, we copy them from project to project. This partially defeats the purpose of an open source set of assertions that we can all contribute to and share.

There will always be reason to have your own extensions to strikt for per-project types but the chance for "sharing" is also extremely high. We have a large number of extensions that we use repeatedly. I'd love to contribute ours and benefit from a group effort to define extended assertions.

Some example of extremely useful assertions that we have shared throughout our code:

• Java Time
  Extensions for things like isWithin(Duration)
• HTTP
  JDK/Apache Client/Quarkus Rest extensions to do things like expectThat(response).isSucccessful { ...optionally assert body... }

We live in a world where agents can take on most of the maintenance burden so we need to either add contributors and get the machinery updated or fork the project and build from there.

After the core project has been updated, I'd love to see an easy/automated way for maintainers to add extension libraries and possibly Kotlin multi-platform support. This would ensure the long term viability of Strikt and really ramp up the sharing for all who love the basic design, as we do.

[viluon]

Note

This is not entirely on-topic but may be relevant to people following this issue. I consider it a PSA.

FWIW, I have found Strikt-style asserts to encourage antipatterns in testing code. You may actually want to decrease your reliance on Strikt rather than trying to extend/revive it. YMMV.

Essentially, Strikt is great when part of what you're asserting isn't deterministic, so a simple equality comparison (like Kotest's shouldBe) doesn't fit. But 99% of tests should be deterministic. Nondeterministic tests often benefit more from an abstraction layer that filters the nondeterministic parts out.

Tests that rely on simple equality comparisons in asserts are simpler to author and review and simultaneously provide more guarantees. That naturally leads to more refactoring when the systems under test change, which, if undesirable, may be better avoided with something like snapshot testing (which under the hood is again a simple equality comparison).

At work, adoption of Strikt in unit tests led to assertions that guaranteed too little and to an overuse of Strikt expectation builders for what were conceptually just equality comparisons on data classes. Switching unit tests to Kotest's shouldBe (which also gives nice diffs out of the box) was a major improvement. We still use Strikt in a few integration tests that involve hard-to-avoid nondeterminism but, long-term, Strikt doesn't seem like a robust solution. Mocking nondeterministic behaviour out as much as possible and mapping to simple data class/sealed interface models in the remaining places seems a much better approach. I'm quite confident that tests of well-factored APIs shouldn't need Strikt.

I'd be interested to hear about Strikt use cases I didn't consider. Property-based tests come to mind but it's hard to imagine a prop test where Strikt would meaningfully improve readability.