How's about something like this to help in asserting against sealed classes/interfaces children types (not too sure about the name though...), I seem to do this alot...:

inline fun <reified T, R> Assertion.Builder<*>.getFromA(noinline function: T.() -> R): Assertion.Builder<R> =
        isA<T>().get(function.describe(), function)

would it make sense to restrict

T

to being a subtype of whatever the current subject is?

in strikt how would i assert that an Optional does not contain a Throwable, and when it does print the throwable including stacktrace?

how would i assert that in a list one element comes before the other?

expectThat(listOf(A,B,C)) {
  get {indexOf(A)}.isLowerThan(….)
}

Couldn't you just do

expectThat(data).dataAssertion()

huh, that overload looks pointless. I should be able to remove the 2nd version of that method

Any input on how to ditch the

unwrap

? If so, is this ^ worth a PR?

Hello, When using JUnit assertions, Intellij adds "see difference" button to check the expected and actual values, but when using strikt it does not, which is annoying for long values. Is there a way to make Intellij add the "see difference" button when using strikt?

Hello 😁 I'm trying to do some asserts using BigDecimal. Hope you guys can help me out

what’s the proper way to chain assertions on unrelated subjects?

expect {
    expectThat(foo) {
        // ...
    }
    expectThat(bar) {
        // ...
    }
}

is there a changelog for 0.34.1?

For this:

expectThat(result) {
			size.isEqualTo(4)
			withElementAt(3) {
...

I get this:

Mapping 'element at index 3 %s' failed with: Index 3 out of bounds for length 3
Mapping 'element at index 3 %s' failed with: Index 3 out of bounds for length 3
	at app//strikt.internal.AssertionBuilder.with(AssertionBuilder.kt:138)
	at app//strikt.assertions.IterableKt.withElementAt(Iterable.kt:70)

Whereas I would have expected the

size.isEqualTo(4)

would give me the size of the array BEFORE crashing on an out of bounds error... or even better, for soft-expectations, maybe not crash at all? Just give an

x

just like any other failed assertion at the appropriate level?

is there a way to only report failures in a large compound assertion to avoid the noise of everything that passed?

I have a related idea: use something like pitest to test your test suite. and mark all assertions that never fail as suspicious. you would run a longer test task that mutates your code to check if it can get all your assertions to fail. and also display a report of the error message, then you can check that the error messages make sense.

I wonder if there’s a way to prevent

isA

if the generic type of the function has its own generic type

I don't think there is a way to prevent it compile time, but you can always just half-botch it by having the assert always fail when

T::class.typeParameters

is non-empty (eg, the reified class has some generic parameters on it's own)

withCaptured

(mockk) breaks assertion chaining if the slot has not been captured. It throws

Mapping 'captured value %s' failed with: lateinit property captured has not been initialized

. Not sure if this is known or intentional. Would be nice if instead of throwing it would short circuit the block and fail.

comparables have `isGreaterThan`/`isGreaterThanOrEqualTo`/etc assertions but no check if equal using

compareTo

which is useful for things like

BigDecimal

maybe add this?

fun <T : Comparable<T>> Assertion.Builder<T>.compareToEqual(expected: T) =
    assert("is equal using compareTo to %s", expected) {
        if (it.compareTo(expected) == 0) pass() else fail()
    }

Would be nice to have a version of

propertiesAreEqualTo

that doesn’t require

other

to be the same type as the subject. Just a couple minor tweaks.

fun <T : Any> Assertion.Builder<T>.reflectionEquals(
    other: Any,
    ignoredPropertyNames: List<String> = emptyList()
): Assertion.Builder<T> = compose("is equal field-by-field to %s", other) { subject ->
    val otherBeanInfo = Introspector.getBeanInfo(other.javaClass)
    val beanInfo = Introspector.getBeanInfo(subject.javaClass)
    beanInfo.propertyDescriptors
        .filter { it.name != "class" && it.name !in ignoredPropertyNames }
        .forEach { property ->
            val mappedAssertion = get("value of property ${property.name}") {
                property.readMethod(this)
            }
            val otherProperty = otherBeanInfo.propertyDescriptors.firstOrNull { it.name == property.name }
            val otherValue = otherProperty?.let { it.readMethod(other) }
// the rest is the same as propertiesAreEqualTo

It says in the docs:

Block assertions do _not_ fail fast.

but if I use:

expectThat(result) {
  get(Foo::prop1)...
  get(Foo::prop2)...
}

It seems to only print out the first check's result... 🤔

I wonder if

expectThat(...)

was an

inline fun

with reified type param, you could technically pass that type down to the assertions and it could be a great help for things like collections... currently if I pass a

List<Foo>

to

expectThat

I can pass a

List<Baz>

that doesn't inherit from

Foo

to

contains

and that simply doesn't make sense... meaning refactoring to passing another type in the list could easily have the tests pass even though they shouldn't...

Kotlin assertion libraries - JUnit, Hamkrest and Strikt

What about https://github.com/bnorm/kotlin-power-assert

I’ll have to check it out, but I have to edit out enough building time from my videos without a compiler plugin!

Are all the existing tests supposed to pass? I cloned the repo and ran

ArrayAssertions

but am getting strange failures where it's complaining about differing strings that appear to be equal so I wonder if I'm running into some sort of character encoding issue:

▼ Expect that "▼ Expect that ['f', 'n', 'o', 'r', 'd']:
              |  ✗ array content equals ['d', 'i', 's', 'c', 'o', 'r', 'd']":
  ✗ is equal to "▼ Expect that ['f', 'n', 'o', 'r', 'd']:
                |  ✗ array content equals ['d', 'i', 's', 'c', 'o', 'r', 'd']"
          found "▼ Expect that ['f', 'n', 'o', 'r', 'd']:
                |  ✗ array content equals ['d', 'i', 's', 'c', 'o', 'r', 'd']"

The way the tests are written makes it very difficult (and frustrating) to deal with test failures because: 1. Double-clicking on a failed test in IntelliJ doesn't navigate to the failing test 2. Clicking the

Rerun Failed Tests

button makes it seem like they all pass because it doesn't actually rerun any tests I don't have these issues when I use Strikt for testing my own project so I wonder if this is caused by using contexts instead of a separate test method per scenario

Since Kotlin 1.8 no longer supports JVM target 1.6 or 1.7: https://kotlinlang.org/docs/whatsnew18.html#updated-jvm-compilation-target then I think this ticket might no longer apply: https://github.com/robfletcher/strikt/issues/41

Once this PR gets merged: https://github.com/robfletcher/strikt/pull/280 Then I'd like to make another unrelated improvement to that file to speed up CI build times

This should speed up CI builds on future submissions: https://github.com/robfletcher/strikt/pull/281

I finally found the root cause of the test failures. It turns out that they are valid failures that shouldn't pass whenever the

line.separator

system property is anything other than

\n

. This is because raw / triple-quoted strings are hard-coded to always be compiled with

\n

line separators so they can't possibly match output that uses the

line.separator

system property. I didn't find any official documentation about this but found this: https://stackoverflow.com/questions/48933641/kotlin-add-carriage-return-into-multiline-string#:~:text=Kotlin%20multiline%20strings%20are%20always,separator%22))%20. and also found that the Kotlin standard library hardcoded

\n

in the

reindent

function (which is used by the

trimIndent

&

trimMargin

functions that are used throughout the tests): https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/src/kotlin/text/Indent.kt#:~:text=.joinTo(StringBuild[…]eEstimate)%2C%20%22%5Cn%22) So this brings up 2 issues: 1. The github action to run on windows doesn't seem to represent a regular windows environment. Perhaps something is overwriting the

line.separator

system property. 2. Either the

EOL

value in

DefaultResultWriter

should be set to

\n

(which makes the tests pass) or all the tests that assert against multi-line triple-quoted strings need to be fixed.

I'm trying to create a couple strikt assertions for this `Result`: https://github.com/michaelbull/kotlin-result I'd like to replace usages like

.isA<Ok<Foo>>().get { value }

with

.isSuccess<Foo>()

but I'm having trouble w/ the generic signatures.

fun <V> Assertion.Builder<Result<V, *>>.isSuccess(): Assertion.Builder<V> = isA<Ok<V>>().get { value }
fun <E> Assertion.Builder<Result<*, E>>.isFailure(): Assertion.Builder<E> = isA<Err<E>>().get { error }

IntelliJ is yelling at me. Any ideas on what these ext funs should look like? Thanks.

propertiesAreEqualToIgnoring

doesn't support nullable attributes as currently written this should work, though

fun <T : Any> Assertion.Builder<T>.propertiesAreEqualToIgnoring(
    other: T,
    vararg ignoredProperties: KProperty1<T, Any?>,
): Assertion.Builder<T> = compareFieldByField(
    other,
    ignoredProperties.map(KProperty1<T, Any?>::name)
)

Just changed

KProperty1<T, Any>

->

KProperty1<T, Any?>