Expansion of #31

For assertion functions like isEqualTo it's essential to have diff capabilities. Need to research and implement how to format the rendering of the "actual" value so that IntelliJ will know to offer a diff button.

Since I set up workflows. Probably doing something wrong.

Too much chance of error. I don't think mkdocs supports it though so may have to pre-process or use something else.

“Honeydew” has been suggested. I quite like it even though I’m allergic to the fruit.

For example can we do something like this?

expect("foo").not.isEqualTo("bar")

…in installation instructions

On assertion fails, it would be really useful to have custom error messages prepended to the regular output.

Currently, a workaround is using subjectDescription:

expect("loading view should be gone: %s", loadingView.visibility).isEqualTo(View.GONE)

Here's what other libraries do:

// Google-truth
assertWithMessage("My custom message on failure")
  .that(view)
  .isNotNull();

// AssertJ
assertThat(view)
  .as("My custom message)
  .isNotNull()

This would be in a new strikt-mock module.

Post 1.0

I think because of the filtering done in the copyspec in the publishGhPages task.

• Automatically populate property names when using map
• Type-aware format:
  • Quote strings
  • Transform ()->Unit to something representative
  • Canonical class name
  • Recurse for collections
• Highlight type when toString of actual and subject are the same #19
• Nest results for block-style expect

Sigh

Allow reporting to write in a variety of formats. Colorized ANSI text for a start.

I'd like proper multi-page docs with the Dokka-generated API docs properly integrated. They should get pushed to gh-pages by Gradle as part of the release process.

I’m in favor of an indeterminate status

Large objects with a huge toString produce pretty unreadable assertion failures. It would make sense to trim to a maximum length.

See the implementations of Assertion<Boolean>.isTrue() / isFalse().

Should include details if no exception or the wrong type was thrown.

fun <T> expect(subjectDescription: String, subject: T): Assertion<T>
and
fun <T> expect(subject: T, block: Assertion<T>.() -> Unit): Assertion<T>
are indistinguishable to the compiler when using a String subject.

Is it an assertion on a ()->* subject with a description or a block assertion on a String?

This needs to not happen.

Dokka can generate markdown and it's possible to include it in the Mkdocs generated site but:

• You have to list all the files in the mkdocs.yml
• The styling needs some work for it to be legible

Reasons this may be desirable:

1. Receivers are neat but not necessarily as readable.
2. Name conflicts are not handled very well if a variable in the test has the same name as a field in e.g. AssertionContext.

For nested assertions they don't reflect the overall assertion state.

Optionally include breakdown of passed assertions in output

I'd like to not expose allFailed, etc. unless nested exceptions are actually being used.

Adding extensions for Android will allow some often-used assertions to be shorter and more idiomatic. For example, we could have:

expect(view).isGone()

instead of

expect(view.getVisibility()).isEqualTo(View.GONE)

A good starting point for these might be assertj-android: https://github.com/square/assertj-android

Blocked by bintray/gradle-bintray-plugin#234

Additional assertions should be added to the strikt.assertions package.

Some ideas:

CharSequence

• contains(String)
• isNumeric()
• isEqualToIgnoringCase(String)

Collection

• map to sub-sequence

Map

• isEmpty()
• contains(K, V)
• containsKey(K)

Data classes / POJOs

• isIndenticalTo(T) (property-by-property equality)
• propertyEquals(Any) (shortcut for map(KProperty0).isEqualTo(expected))

Arrays

• contentEquals(T) (delegate to same method on Kotlin's Array type)

Add some useful extension properties and methods for common uses of Assertion<T>.map(()->R): Assertion<R>

• Assertion<Any?>.toString
• Assertion<Collection<E>>.first() etc.
• Assertion<List<E>>.get(IntRange) etc.

Looks like dokkaJar and bintrayUpload tasks are running concurrently. If the jar is already built it's fine but if not the upload fails.

Dokka jar gets overwritten with an (empty) javadoc jar during release using gradle final. Probably need to suppress the Nebula javadoc jar plugin.

If an assertion is not evaluated because the chain before it broke it would be nice to see that in the output.

Should properly log assertion results to JUnit's stream.

I think this can be done by maintaining some kind of chain and only throwing if the assertion is at the end