This message was deleted.

Truth development ceased many years ago, so there should be strong reasons for using Truth for the new projects 🤷‍♂️

do you have a reference for the assertion (😉 ) that Truth is dead?

I've got something like this here https://github.com/vanniktech/gradle-maven-publish-plugin/blob/main/plugin/src/integrationTest/kotlin/com/vanniktech/maven/publish/Subjects.kt#L98 but it's very specific for what we need in the publish plugin tests

@tony, see https://github.com/google/truth/issues/893#issuecomment-947130146 > anything that we label as P3 has no timeline for being reviewed 😞 > We hope to eventually schedule some more time for Truth (especially for features that could work well in Kotlin, like this one), but there are no plans yet. Virtually all the currently open issues are

P3

, so the team are effectively out of capacity to review them. There are multi-year PRs which do not get reviewed either: https://github.com/google/truth/pulls The sole contributor nowadays is

cpovirk

(see https://github.com/google/truth/graphs/contributors ), and the commits for the past 3 years are more like small cleanup ones: https://github.com/google/truth/commits?author=cpovirk&since=2019-07-18&until=2024-01-15 Well, Truth does not play well with JUnit5, and the ask to move from JUnit4's

ComparisonFailure

to opentest4j was met with “oh, we can’t break backward compatibility” (see https://github.com/google/truth/issues/333#issuecomment-1020348512) Of course, backward compatibility is super important, however, there are many ways to support JUnit5. For instance, one could throw either JUnit4's exception or opentest4j’s one depending on the configuration. For instance, if I use JUnit5, I do not want having JUnit4 on the classpath, so I have just one

@Test

annotation instead of multiple ones. All-in-all, I like how Truth favours clear exception messages, however, the team has no capacity to review issues and PRs, so de-facto the development halted.

Well, Truth is a Google project that works like many other Google projects: they're made for their internal needs first.

Well,

project.name

is a

project.findProperty("owner")

project that works like many other

project.findProperty("owner")

projects: they’re made for their internal needs first.

That is universally true for

allprojects

🙂 At the same time, Guava gets more attention from

cpovirk

(see https://github.com/google/guava/graphs/contributors ). -- It looks like there’s a some activity in Truth regarding Kotlin (e.g. https://github.com/google/truth/issues/849 ), however, the approach Truth and AssertJ follow does not work well for Kotlin, so I doubt there will be any improvements in that area soon. In other words, both Truth and AssertJ are limited to whatever extensibility Java provides, and it makes it hard to add extensions (e.g. AssertJ requires nested generics and custom subject builders)

i don't really see the problem. it's ok for a library to be largely "done." I use Truth in many of my test suites, for example in my Spock tests and my Kotlin JUnit5 tests. I don't know what you mean about it not playing well with Kotlin. I guess the most annoying thing is that it puts JUnit4 on the classpath, but that's a simple fix - I exclude JUnit4 artifacts from all configurations.

> I don’t know what you mean about it not playing well with Kotlin Can you add an extension to the existing Truth Subjects without inheriting them and replacing all the usages? Methods like

protected final void failWithActual

are

protected

in Truth, so you can’t extend

ProtoSubject

with something like

ProtoSubject.fieldsDoNotContain("qwerty")

--- > my plugin sometimes goes months without any development, and there are issues that have been open for years, some of which may never get worked on - is it not under active development? should people not use it? Frankly, if the maintainer is mostly inactive and they explicitly say they have no time on checking out issues, and they explicitly say they have no time on reviewing PRs and there are no signs of adding new maintainers, then it would be tough call to start using the library. Frankly, even if your library goes without any development for ages, I would expect that I can get my PR merged in if I ping you a few times. On the other hand, if I ping maintainers with a perfectly valid PR, and they say “sorry, we have no time on even looking into it”, then, it is a no-go for me. Sure there are “feature complete” libraries, however, assertion library is virtually never feature-complete. Of course, you might consider Truth a “done” project, however, that means you would have to create a golden subset of subjects. For instance, see https://github.com/google/truth/issues/717 (ThrowableSubject does not provide access to suppressed exceptions) One can’t “just add suppressed exceptions” to the existing ThrowableSubject, but they need to inherit and things like that. Of course, it is all doable, however, then you basically go with your own fork of Truth which is, well, not that great. Then the Java community seems to lean towards opentest4j. For instance, Gradle supports opentest4j more and more: https://github.com/gradle/gradle/issues/27007 Truth has no signs of opentest4j support. Adding opentest4j would require patching Truth which is virtually impossible unless one forks Truth which is a tough call as well.

alright. I agree that having to inherit from Subjects is annoying (I just had to do that yesterday in a custom Subject)

I'm testing a testing library which aside from hurting my brain

haha yeah, I know that feeling