Make shouldNotBeNull return non-null instance

[AndreasVolkmann]

Sometimes you want to test whether a nullable instance is actually null.
Most often I want to run futher tests on this instance afterwards.

It would be nice if the shouldNotBeNull fun returned a non null type when the test passes (and throws if not).

Sample implementation:

fun <T : Any> T?.shouldNotBeNull(): T = this ?: throw AssertionError("Expected this to not be null")

This allows one to write the following code:

val user = userSource.findUser(details.email).shouldNotBeNull()
user.email.shouldNotBeBlank()
articleSource.insertArticle(user, it)

Without having to !! every user reference.

[jcornaz]

Totaly agree, I often encounter this use case too.

[MarkusAmshove]

If you want you can review the change before I release it :-)

[MarkusAmshove]

This might also be something worth it for almost all other assertions, to return the value on their happy path

[MarkusAmshove]

A good candidate would be

infix fun Any?.shouldBeInstanceOf(className: Class<*>) = assertTrue("Expected $this to be an instance of $className", className.isInstance(this))

to

inline fun <reified T: Any> Any.shouldBeInstanceOf() : T = if(this::class.isInstance(T::class)) this as T else throw AssertionError("Expected $this to be an instance of ${T::class.qualifiedName}")

which has to be a separate method to not break existing code.

This would allow:

open class Base {
    fun doSomething() = println("Base")
}

class Child : Base() {
    fun different() = println("Child")
}

fun main(args: Array<String>) {
    val base : Base = Child()
    // base.different() - Doesn't compile, not of type Child
    val child = base.shouldBeInstanceOf<Child>()
    child.different()
}```

[AndreasVolkmann]

Exactly, it should help wherever possible.

Why did you put this as in next release and needs migration to 2.0 ?

[MarkusAmshove]

in next release means that it'll the in the next version that is released (pushed/merged to master, waiting to be released).

Migration to 2.0 is just to keep track of changes that aren't in the 2.0 branch yet. They have to be migrated by hand, because the repository and project structure changes for 2.0.
It makes sure that 2.0 will be on par with the latest 1.x version feature wise ;-)

[MarkusAmshove]

I'm tracking the other stuff in #91 to collect most assertions which make sense.

I hope to get everything ready and released this weekend :)

[MarkusAmshove]

I've just released these changes with v1.34