Any opinions about making `.shouldBeSingleton()` a...

# kotest

[Sebastian Schuberth]

Any opinions about making .shouldBeSingleton() actually return the singleton instead of the original (single-valued) collection? That would allow for nicer chaining of assertions, like .shouldBeSingleton().shouldBeSuccess().

[sam]

I think that makes sense

[sam]

https://github.com/kotest/kotest/issues/6027

[Sebastian Schuberth]

It's a breaking change, though, I guess...

[sam]

it is ... which is why I made the ticket instead of just doing it, because we need to think about it

[sam]

you're right, its better tho

[Sebastian Schuberth]

👍🏻

[CLOVIS]

The stdlib has List<T>.single(): T for that, so maybe shouldBeSingle() can be added without breaking the existing method?

[Sebastian Schuberth]

Sounds good to me! I always found "singleton" a bit misleading here, as it has nothing to do with the "singleton design pattern" (for classes).

[sam]

agreed. So deprecate original, add shouldBeSingle

[Sebastian Schuberth]

Or maybe not even deprecate. It's just two different functions then.

[sam]

true

[sam]

I've set claude on it

[sam]

we're releasing 6.2 this week I think, so it'll go into that

[sam]

https://github.com/kotest/kotest/pull/6028

[Klitos Kyriacou]

I agree that we should keep the original method and just add shouldBeSingle. The original method could still be used like this:

actualCollection.shouldBeSingleton().shouldBeTypeInstanceOf<Set<X>>() shouldBe expectedCollection

Also, note that the original post could be written like this, using only existing methods:

actualCollection.shouldBeSingleton { it.shouldBeSuccess() }

[Olaf Gottschalk]

Just my five cents: I always struggled with this as well. It is counterintuitive that shouldBeSingleton() returns the collection and not the single element....