I did a bit of playing around with this and wrote a few tests for the suspending functions, and I never had a single issue.

Conceptually, I think it would make the most sense to have all functions that produce a subject be suspending functions, while the lambdas on asserts should not be, which is why I marked all of expect {} and catching {}. By the time the test is evaluating assertions, the data should be loaded already, and so probably shouldn't be running more the complex coroutine logic.

Also, I've never used gradle dependency locking and couldn't figure out how to get Gradle to work with the Kotlinx Coroutines dependency, and so just commented it out for now.

I've witnessed a very strange behavior of strikt 0.29.0 (as well as 0.30.0) today. Please consider the following self-contained test:

import org.junit.jupiter.api.Test
import strikt.api.expectThat
import strikt.assertions.hasSize
import strikt.assertions.single

class StriktTest {

    @Test
    fun thisWillFailAsIntended(){
        val list = listOf("hello", "foo")

        expectThat(list).hasSize(3).and { // fails the "hasSize" condition, as it should.
            get { this.filter { it == "foo" } }.single()
        }
    }

    @Test
    fun thisWillActuallyPass() {
        val list = listOf("hello", "foo")

        expectThat(list) {
            hasSize(3) // we have 2 items in the list, yet the test passes
            get { this.filter { it == "foo" } }.single()
        }
    }

    @Test
    fun thisWillActuallyPassToo() {
        val list = listOf("hello", "foo")

        expectThat(list) {
            get { this.filter { it == "foo" } }.single()
            get { this.filter { it == "bar" } }.single() // "bar" is not even in the list - yet the test passes!
        }
    }

}

To my amazement, the second and third test will actually pass. Even though the list certainly doesn't match all of the given criteria.

I can't explain why that's the case. Did I do something horribly wrong with the API? Did I mis-interpret some of the methods?

Would be great to use this library in Android development but some latest changes aren't compatible with lower Android versions than 24.

Private interface methods are only supported starting with Android N (--min-api 24): 
Lstrikt/api/Assertion$Builder;describe(Lkotlin/jvm/functions/Function1;)Ljava/lang/String;

Any ideas to workaround this issue?

Before adding opentest4j dependency, it shows this exception whenever assertion failed occur:

java.lang.NoClassDefFoundError: org/opentest4j/AssertionFailedError
	at strikt.internal.AssertionStrategy.createAssertionFailedError$strikt_core(AssertionStrategy.kt:195)
	at strikt.internal.AssertionStrategy$Throwing.afterStatusSet(AssertionStrategy.kt:151)
	at strikt.internal.AssertionStrategy$appendAtomic$1.fail(AssertionStrategy.kt:44)
	at strikt.api.AtomicAssertion$DefaultImpls.fail$default(AtomicAssertion.kt:19)
	at strikt.assertions.CollectionKt$hasSize$1.invoke(Collection.kt:12)
	at strikt.assertions.CollectionKt$hasSize$1.invoke(Collection.kt)
	at strikt.internal.AssertionBuilder.assert(AssertionBuilder.kt:64)
	at strikt.internal.AssertionBuilder.assert(AssertionBuilder.kt:11)
	at strikt.assertions.CollectionKt.hasSize(Collection.kt:9)
       at ....
	at org.spekframework.spek2.runtime.scope.TestScopeImpl.execute(Scopes.kt:94)
	at org.spekframework.spek2.runtime.Executor$execute$$inlined$executeSafely$lambda$1$1.invokeSuspend(Executor.kt:52)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:740)
Caused by: java.lang.ClassNotFoundException: org.opentest4j.AssertionFailedError
	at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 18 more

After I added testImplementation group: 'org.opentest4j', name: 'opentest4j', version: '1.2.0', everything works fine.

I'm using spek version 2.0.6 for testing an Android app. It works fine with other assertion library like AssertJ.

P/S I think it is still not fine after I adding opentest4j dependency. Here is what I got after addin the dependency:

  ✗ has size 2 : found 1
org.opentest4j.AssertionFailedError: ▼ Expect that [Mock for Class, hashCode: 17337594]:
  ✗ has size 2 : found 1
	at ...
	at ....
	at org.spekframework.spek2.runtime.scope.TestScopeImpl.execute(Scopes.kt:94)
	at org.spekframework.spek2.runtime.Executor$execute$$inlined$executeSafely$lambda$1$1.invokeSuspend(Executor.kt:52)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:594)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.access$runSafely(CoroutineScheduler.kt:60)
	Suppressed: org.opentest4j.AssertionFailedError
		at strikt.internal.AssertionStrategy.createAssertionFailedError$strikt_core(AssertionStrategy.kt:195)
		at strikt.internal.AssertionStrategy$Throwing.afterStatusSet(AssertionStrategy.kt:151)
		at strikt.internal.AssertionStrategy$appendAtomic$1.fail(AssertionStrategy.kt:44)
		at strikt.api.AtomicAssertion$DefaultImpls.fail$default(AtomicAssertion.kt:19)
		at strikt.assertions.CollectionKt$hasSize$1.invoke(Collection.kt:12)
		at strikt.assertions.CollectionKt$hasSize$1.invoke(Collection.kt)
		at strikt.internal.AssertionBuilder.assert(AssertionBuilder.kt:64)
		at strikt.internal.AssertionBuilder.assert(AssertionBuilder.kt:11)

        expect {}.throws<java.lang.RuntimeException>() // this works
        expect {"blah"}.throws<java.lang.RuntimeException>() // this is red in idea
        throws<RuntimeException> {"blah"} // this works

this is a really strange problem, the kotlin compiler seems to be fine with a ()-> Unit block returning something in line 3 but in line 2 it complains

or maybe even three times if you count the expected: null

this is with current master.

the output for this one line: expect(listOf(1,2,3)).containsExactly(1,2)

is

Expected :null
Actual   :[3]
 <Click to see difference>



strikt.internal.opentest4j.CompoundAssertionFailure: ✗ contains exactly the elements [1, 2]
  ✗ contains no further elements : found [3]

	at strikt.internal.CompoundAssertionNode.toError(AssertionNode.kt:136)
	at strikt.internal.AssertionNodeKt.toErrors(AssertionNode.kt:144)
	at strikt.internal.AssertionNodeKt.access$toErrors(AssertionNode.kt:1)
	at strikt.internal.AssertionSubject.toError(AssertionNode.kt:73)
	at strikt.internal.AssertionGroup$DefaultImpls.throwOnFailure(AssertionNode.kt:31)
	at strikt.internal.AssertionSubject.throwOnFailure(AssertionNode.kt:40)
	at strikt.internal.AsserterImpl.throwOnFailure(AsserterImpl.kt:168)
	at strikt.internal.AsserterImpl.access$throwOnFailure(AsserterImpl.kt:15)
	at strikt.internal.AsserterImpl$compose$$inlined$let$lambda$1.then(AsserterImpl.kt:147)
	at strikt.assertions.IterableKt.containsExactly(Iterable.kt:145)
...

strikt.internal.opentest4j.CompoundAssertionFailure: ▼ Expect that [1, 2, 3]:
  ✗ contains exactly the elements [1, 2]
    ✗ contains no further elements : found [3]

	at strikt.internal.AssertionSubject.toError(AssertionNode.kt:73)
	at strikt.internal.AssertionGroup$DefaultImpls.throwOnFailure(AssertionNode.kt:31)
	at strikt.internal.AssertionSubject.throwOnFailure(AssertionNode.kt:40)
	at strikt.internal.AsserterImpl.throwOnFailure(AsserterImpl.kt:168)
	at strikt.internal.AsserterImpl.access$throwOnFailure(AsserterImpl.kt:15)
	at strikt.internal.AsserterImpl$compose$$inlined$let$lambda$1.then(AsserterImpl.kt:147)
	at strikt.assertions.IterableKt.containsExactly(Iterable.kt:145)
...

at least in idea.

Hi Folks,

I've been using strikt in a project and have come to a point where I would like to use the custom assertion feature. Up to now my "custom" assertion has looked like this:

fun assertResult(e: Outcome, r: Response<out Any>) {
        expectThat(r.outcome).isEqualTo(e)
    }

I rewrote the assertion following the guide on the website, and have ended up with the following:

fun Assertion.Builder<Response<out Any>>.hasOutcome(o: Outcome) =
        assert("has outcome of $o") {
            when (it.outcome) {
                o -> pass()
                else -> fail(actual = it.outcome)
            }
        }

This seems to compile fine, however when I actually try and use it I get this error:

expectThat(subject.execute(request, ::id))
            .hasOutcome(Outcome.INVALID_DATA)

//Error:(35, 9) Kotlin: Type mismatch: inferred type is DescribeableBuilder<Response<Brand>> but Assertion.Builder<Response<out Any>> was expected

I can see that DescribeableBuilder does inherit from Assertion.Builder, however it doesn't seem to be able to see the extension methods. If I add an extra assertion in front of my custom one it works fine like so:

expectThat(subject.execute(request, ::id))
            .isA<Response<out Any>>()
            .hasOutcome(Outcome.INVALID_DATA)

However I don't think this should be necessary? Any help is much appreciated!

update: Changing the signature to

    fun <T> Assertion.Builder<Response<T>>.hasOutcome(o: Outcome) =
        assert("has outcome of $o") {
            when (it.outcome) {
                o -> pass()
                else -> fail(actual = it.outcome)
            }
        }

then works, but I'm not entirely sure why since I would have thought that would match any object, regardless of generics?

Hi,

strikts feature to display the actual code passed into a get { thisAndThat } is extremely useful. It's also okay to display the object value as a fallback if the resolver doesn't produce a result. However, under windows, the resolver fails very often for a simple reason:

FilePeek.kt, lines 30 - 36: Here you check for things like "/out/", but when running under windows, the variable classFilePath contains backslashes (\) instead as separators.

Could you please replace the hard-coded / characters by File.separator to make it work under windows too?

Thanks.

this code

    @Test
    fun `jackson`() {
        val node = jacksonObjectMapper().readTree(""" {"blah":"blerg"} """)
        print(node.toString())
        expect(node).map(JsonNode::isBigDecimal).isTrue()
    }

outputs this:

{"blah":"blerg"}

Expected :true
Actual   :false
 <Click to see difference>



strikt.internal.opentest4j.CompoundAssertionFailure: ▼ Expect that [[]]:
  ▼ Expect that .isBigDecimal false:
    ✗ is true : found false

When writing custom assertions, the only way to get the subject is directly from the Assertion receiver's subject parameter. A more idiomatic, Kotlin-y way to access the subject would be having it passed as the sole argument to the callback, which can be accessed implicitly as the it parameter, or be named as needed by the end-user.

The new signature would look something like:

// in strikt/api/Assertion.kt
fun assert(
      description: String,
      expected: Any?,
      assert: AtomicAssertion<T>.(T) -> Unit
    ): Builder<T>

Example usage:

fun Assertion.Builder<LocalDate>.isStTibsDay() =
  assert("is St. Tib's Day") {
    when (MonthDay.from(it)) {
      MonthDay.of(2, 29) -> pass()
      else               -> fail()
    }
  }

or

fun Assertion.Builder<LocalDate>.isStTibsDay() =
  assert("is St. Tib's Day") { dateUnderTest ->
    when (MonthDay.from(dateUnderTest)) {
      MonthDay.of(2, 29) -> pass()
      else               -> fail()
    }
  }

I think that expect(1L).isEqualTo(1) should pass, because its an implementation detail that its a long. also 1L == 1 is true. most other assertion libs seem to not agree with me here, just putting it up for discussion.

maybe isEqualTo should be changed to take T? (or a subtype of T?) instead of Any?? it boils down to the question, should isEqualTo work like the == operator, or like the equals method. right now the docs say that it works like == but in reality it works like equals, and i think it would be better if it worked like ==

I have the following snippet:

expectThat(1) {
  isLessThan(1)
  isLessThan(2)
}

The output is:

▼ Expect that 1:
  ✗ is less than 1
  ✓ is less than 2

Is there a way to omit passed checks to have only

▼ Expect that 1:
  ✗ is less than 1

I have many nested checks for a big collection, and the output is too big to reason.

fun <T> Builder<out Iterable<T?>>.filterNotNull(): Builder<List<T>> =
        get { this.filterNotNull() }

Would make a nice addition to the already existing filter, filterNot and filterIsInstance.

This is a request for a new assertion which checks whether the subject Iterable contains the given elements in order provided, possibly with other items between them. AssertJ has that feature: containsSubsequence(ELEMENT... sequence), though I'm not a fan of that name. I'd call it either containsNonContinuousSequence or containsInOrder (as opposed to just contains, which doesn't verify the order and containsExactly, which checks the order, but doesn't allow other items).

This was already raised in #156 but the closing PR resolved only half of that feature request. Additionally, that PR implemented containsSequence on Lists, but I think it'd make more sense to implement that more broadly on Iterables.

I could try implementing this if that's okay.

Currently if some code wants to handle assertion failures, this doesn't work for strikt helpers like first() because MappingException extends IncompleteExecutionException, not AssertionError. eg:

  private val failures = mutableListOf<AssertionError>()

  fun doSomethingWithFailures(runnable: Runnable) {
    try {
      runnable.run()
    } catch(assertionFailed: AssertionError) {
      failures.add(assertionFailed)
      throw assertionFailed
    }
  }

  private fun thingUnderTest() = emptyList<String>()

  // failure will be added to failures
  @Test
  fun `thingUnderTest has a catflap`() {
    doSomethingWithFailures {
      expectThat(thingUnderTest()).contains("catflap")
    }
  }

  // failure will not be added to failures
  @Test
  fun `thingUnderTest has a catflap first`() {
    doSomethingWithFailures {
      expectThat(thingUnderTest()).first().isEqualTo("catflap")
    }
  }

Would it be better to have MappingException extend org.opentest4j.AssertionFailedError instead?

The function is very useful but unfortunately Java introspection seems to have its own ideas about naming, so that properties are not ignored when their name starts with a lowercase letter immediately followed by an uppercase letter:

class PropertiesDemo {
    data class Bean(
        val lowercase: String,
        val camelCase: String,
        val bRoken: String,
    )
    val bean = Bean("bean", "bean", "bean")

    @Test
    fun camelCase() {
        val copied = bean.copy(camelCase = "different")
        expectThat(copied).propertiesAreEqualToIgnoring(bean, Bean::camelCase)
    }

    @Test
    fun lowerCase() {
        val copied = bean.copy(lowercase = "different")
        expectThat(copied).propertiesAreEqualToIgnoring(bean, Bean::lowercase)
    }

    @Test
    fun bRoken() {
        val copied = bean.copy(bRoken = "different")
        expectThat(copied).propertiesAreEqualToIgnoring(bean, Bean::bRoken)
    }
}

When you run the above tests, you'll find that strikt sees the property Bean::bRoken as "BRoken" and therefore does not ignore it and fails the test.