ychescale9 / Kluent

Fluent Assertion-Library for Kotlin

Kluent

Kluent is a "Fluent Assertions" library written specifically for Kotlin.

It uses the Infix-Notations and Extension Functions of Kotlin to provide a fluent wrapper around the JUnit-Asserts and Mockito.

How to contribute

Platform	Status
MacOS / Linux
Windows

---

Include it via gradle/maven

Kluent is hosted here at jcenter

Kluent-Android is hosted here at jcenter

Gradle

Replace {version} with the current version and chose one of the two artifacts, based on your target platform:

// Add jcenter as a repository for dependencies
repositories {
    jcenter()
}

dependencies {
    // for JVM:
    testImplementation 'org.amshove.kluent:kluent:{version}'

    // for Android:
    testImplementation 'org.amshove.kluent:kluent-android:{version}'
}

Maven

Replace {version} with the current version

<!-- Add jcenter as a repository for dependencies --> 
<repositories>
    <repository>
        <id>jcenter</id>
        <url>https://jcenter.bintray.com/</url>
    </repository>
</repositories>

<dependency>
    <groupId>org.amshove.kluent</groupId>
    <artifactId>kluent</artifactId>
    <version>{version}</version>
    <type>pom</type>
</dependency>

---

Examples

More examples can be seen on the Site or in the tests.

assertEquals

"hello" shouldEqual "hello"

assertNotEquals

"hello" shouldNotEqual "world"

Assert that an Array/Iterable contains something

val alice = Person("Alice", "Bob")
val jon = Person("Jon", "Doe")
val list = listOf(alice, jon)
list shouldContain jon

Stubbing

val stub = mock(Database::class)
val bob = Person("Bob", "Guy")
When calling stub.getPerson() itReturns bob

Using backticks

Every method that is included in Kluent also has a "backtick version", to make it feel more like a describing sentence.

Some examples:

assertEquals

"hello" `should equal` "hello"

assertNotEquals

"hello" `should not equal` "world"

Building Kluent

All projects of Kluent are built with Gradle

The default gradlew build will only build the common and jvm module, to keep the build times as small as possible.

If you plan to submit a pull request, it is also fine if you just make sure it builds and tests against common and jvm (which gradlew build will make sure of), because the rest of the heavy work will be done by Travis and AppVeyor. That way you can keep your machine free from NodeJS and Kotlin Native :-)

To build the Android library, pass the parameter ANDROID to Gradle. This will build the common and android artifacts. To pass the parameter, type:

gradlew build -PANDROID

To also build the JS module, pass JS:

gradlew build -PJS

To build native, pass:

gradlew build -PNATIVE

In these cases, the JVM module will also be built, because it is our primary target and everything should pass on the JVM. To skip the JVM build, e.g. for testing only against Native or JS, pass SKIPVM:

gradlew build -PJS -PNATIVE -PSKIPJVM

This command will build common, js, native, but not jvm.

Where to put new features

If you plan to add a feature (e.g. an Assertion), it would be nice to first try adding it to the common module, as it would then be available to all platforms. If it uses specific APIs, like classes from the Java standard library, then it needs to go to the jvm module.

If you're unsure where to put a feature, or if you want to put something in the common module which needs platform specific implementations, you can have a look here (platformIsDigit or platformClassName) where a function in the common module calls a so called expect function, which is defined here in the common module and has specific JVM, JS and Native implementation.

If you're still unsure how to make something platform independent, we can have a look together inside the PR :-)