robfletcher / strikt Goto Github PK

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.

For example can we do something like this?

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

Sigh

• 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

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()

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

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

I’m in favor of an indeterminate status

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)

Optionally include breakdown of passed assertions in output

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.

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

Expansion of #31

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

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

This would be in a new strikt-mock module.

Post 1.0

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

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

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

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

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.

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 jar gets overwritten with an (empty) javadoc jar during release using gradle final. Probably need to suppress the Nebula javadoc jar plugin.

Blocked by bintray/gradle-bintray-plugin#234

Since I set up workflows. Probably doing something wrong.

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.

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

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

Should properly log assertion results to JUnit's stream.

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

…in installation instructions

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

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