@danny here’s a good issue for the Gradle expert! https://github.com/robfletcher/strikt/issues/22

@robfletcher will strikt support kotlin multiplatform or just the JVM?

I worked with some of your open source stuff and watched some of your talks, you could almost say you have a fan 😄

Just recently fixed the issue on java 10 for spek. You're using

2.0.0-alpha.1

right?

ooh, interesting

how can i group 2 asserts that use a different subject?

so i think when actual is null, isActualDefined needs to be false

(obviously with a better name than

f

)

Couple of issues: - it highlights test output in the snippets as though it was Kotlin code - the search doesn’t appear to work (not sure if that’s just locally but I see errors in the JavaScript console)

is there a way to detect expectations that can never fail, like

expectThat("blah").isA<String>()

?

most of the time it is just a String, but I think the Nebula plugins set it as an actual object. But the Orchid gradle plugin expects it to be a String (which is a bug)

I’m on a podcast hosted by a couple of friends of mine talking about Kotlin & Strikt https://soundcloud.com/funtimeexception/episode-210-it-just-wont-quit

I created a PR with initial support for Sorted Assertion on the Collection. Feedback on the API and semantics is very welcome.

Thanks. It shouldn’t require coroutines. Can you give me an example of what you’re running in to?

if want to write a custom assertions for something like

Option<T>

where it is either a

Some

or

None

type, what is the best way to rite those? for example, would it be better to have something like

fun Assertion.Builder<Option<T>>.isSome(asserts: Assertion.Builder<T>.() -> Unit)

or is there a better way to "chain" it where it short circuits the following assertions if it a

None

?

fun Assertion.Builder<Option<T>>.isSome(): Assertion.Builder<T>

This doesn't seem to work...:

inline fun <reified R> Assertion.Builder<Iterable<*>>.filterIsInstance(): DescribeableBuilder<List<R>> =
		get { filterIsInstance<R>() }

?

Another little point: running

expectThat(catching { ... }).isNull()

, if it throws, it doesn't print the exceptions message... in my case:

▼ Expect that com.squareup.moshi.JsonDataException:
  ✗ is null

which doesn't help too much to identify the source of the problem.

@Casey Brooks I tried upgrading to Orchid 0.14.0 but the when I do the

orchidServe

task the images all get 404s

im working on some additional assertions for

File

and

Path

that im hoping to open an MR to

strikt

with, and seeing a few patterns emerge that im hoping to get some early feedback before working through it too much. 1. for certain "getter" style evaluation, is it better to expose as a property or function?

val <T : Path> Builder<T>.fileName: Builder<Path>

versus

fun <T : Path> Builder<T>.fileName(): Builder<Path>

2. for "boolean" style testing, like "is this readable", what is the desired API to expose?

val <T : Path> Builder<T>.isHidden: Builder<Boolean>

or

// assert(...)
fun <T : Path> Builder<T>.isHidden(): Builder<T>
fun <T : Path> Builder<T>.isNotHidden(): Builder<T>

(this gets a bit more complicated with checks like

exists

because the underlying API accepting varargs of

LinkOption

) 3. for assertion style things, is it best to offer multiple APIs for inversions and other possible for example:

fun <T : Path> Builder<T>.startsWith(other: String): Builder<T>
fun <T : Path> Builder<T>.doesNotStartWith(other: String): Builder<T>

or is there an opportunity to add something for consumers like an

doesNot { startsWith(other) }

to reduce API surface?

maybe in soft assertions the stacktrace for the specific failure should be for the line of the assertion and not for the line that contains the expect.

does anyone have an idea how i can remove the duplication in this test: https://github.com/christophsturm/randolf/blob/b5c2eea6d5bd0da587220073ddb4496760b4e17a/src/test/kotlin/randolf/RandolfTest.kt#L84-L117

theres way too many people who do not know that strikt is the best assertion lib

@mkobit Just checked and

strikt-gradle

is in jcenter now

definitely!

Maybe you could also provide a way to do assertions in the wrapped value as well, not just a predicate?

i have an old assertj assertion that uses conditions that is

val hpi = condition<String>(".hpi extension") { it.endsWith("@hpi") }
      val jpi = condition<String>(".jpi extension") { it.endsWith("@jpi") }
      val war = condition<String>(".war extension") { it.endsWith("@war") }
      val jenkinsWar = condition<String>("Jenkins WAR group and module") { it.contains("org.jenkins-ci.main:jenkins-war") }
      assertThat(line)
        .has(anyOf(allOf(war, jenkinsWar), hpi, jpi))

where

condition

is a helper to create https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/Condition.html is there anything comparable in

strikt

yet to accomplish the

anyOf

and

allOf

style composition above?

is there a comparable to AssertJ's

withFailMessage

- https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractAssert.html#withFailMessage-java.lang.String-java.lang.Object...- ?

is

strikt-protobuf

intended to have APIs for both gRPC and protobuf, or only protobuf types? i'm wondering if it makes sense to add another

strikt-grpc

or to shove it into

strikt-protobuf

?

assertion errors on assertion errors are really mindboggling to read. #inception