Kluent alternatives and similar libraries
Based on the "Tests" category.
Alternatively, view Kluent alternatives based on common mentions on social networks and blogs.
-
Kotest
Kotest is a flexible and comprehensive testing tool for Kotlin with multiplatform support. Previously known as Kotlintest - From release 4.0 this project is now known as Kotest -
balin
Balin is a browser automation library for Kotlin. It's basically a Selenium-WebDriver wrapper library inspired by Geb. -
arbitrater
Arbitrater is a library for creating arbitrary (randomized) instances of classes by reflection for use in testing. -
kwik
A property-based testing library for Kotlin. Execute tests with randomized inputs with a test-engine agnostic and compile-time safe library.
Get performance insights in less than 4 minutes
Do you think we are missing an alternative of Kluent or a related project?
Popular Comparisons
|
SaaSHub - Software Alternatives and Reviews
Sponsored
www.saashub.com
|
README
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](CONTRIBUTING.md)
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}'
// To get JUnit errors from kotlin.test, to e.g. enable diff windows in failure messages
testImplementation "org.jetbrains.kotlin:kotlin-test-junit:$kotlin_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" shouldBeEqualTo "hello"
assertNotEquals
"hello" shouldNotBeEqualTo "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 be equal to` "hello"
assertNotEquals
"hello" `should not be equal to` "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 :-)