All Versions
Latest Version
Avg Release Cycle
14 days
Latest Release
870 days ago

Changelog History
Page 5

  • v3.1.8 Changes

    • ๐Ÿ›  Bugfix: Skip tests when MethodSelector is set #367 (means can run a single test in intellij)
    • ๐Ÿ›  Bugfix: Fix error when running single test in kotlintest-tests (#371)
    • ๐Ÿ›  Bugfix Fix table testing forNone and Double between matcher (#372)
    • ๐Ÿ‘Œ Improvement: Remove matcher frames from stacktraces (#369)
    • ๐Ÿ‘Œ Improvement: Use less ambiguous string representations in equality errors (#368)
    • ๐Ÿ‘Œ Improvement: Improve String equality error messages (#366)
    • โšก๏ธ Internal: Update kotlin to 1.2.50 (#365)
  • v3.1.7 Changes

    • ๐Ÿ”‹ Feature: Added Int/Long.shouldBeNegative and Int/Long.shouldBePositive matchers #325
    • ๐Ÿ”‹ Feature: Added Double.shouldBeNegative and Double.shouldBePositive matchers #325
    • ๐Ÿ”‹ Feature: Added collection.shouldBeLargerThan(c), collection.shouldBeSmallerThan(c), collection.shouldBeSameSizeAs(c) #325
    • ๐Ÿ”‹ Feature: Added collection.shouldHaveAtLeastSize(n) and collection.shouldHaveAtMostSize(n) matchers.
    • ๐Ÿ”‹ Feature: Added matcher for uri.opaque
    • ๐Ÿ”‹ Feature: Add matchers containsExactly and containsExactlyInAnyOrder (#360)
    • ๐Ÿ”‹ Feature: Added test case filters
    • ๐Ÿ›  Bugfix: Running single tests with Gradle command line #356
    • ๐Ÿ”„ Change: Removed coroutine support until it is no longer experimental
    • ๐Ÿ‘Œ Improvement: Optimize sorted matcher (#359)
    • ๐Ÿ‘Œ Improvement: Allow type matchers to match nullable values. (#358)
    • ๐Ÿ‘Œ Improvement: Allow nullable receivers for string matchers. (#352)
    • ๐Ÿ‘Œ Improvement: Run tests for all rows in a table, even after errors. (#351)
  • v3.1.6 Changes

    • โœ… Specs now support co-routines #332
    • Extension function version of inspectors.
    • Inspectors for arrow NonEmptyLists
    • ๐Ÿ†• New style of data driven tests with parameter name detection
    • ๐Ÿ’… Extension function style of assert all for property testing
    • โšก๏ธ Updated string matchers to show better error when input is null or empty string
    • ๐Ÿ‘ Allow nullable arguments to more matcher functions. #350
    • โž• Added extension functions for table tests #349
  • v3.1.5 Changes

    • ๐Ÿ›  Fix for bug in gradle which doesn't support parallel test events
    • โœ… Bring back Duration extension properties #343
    • โž• Added fix for gradle 4.7 issues #336
    • โœ… shouldBe does not handle java long #346
    • ๐Ÿ›  Fixing function return type in documentation for forAll() (#345)
    • ๐Ÿ›  Fixing typos in (#344)
    • โœ… Make the Table & Row data classes covariant (#342)
    • ๐Ÿ›  Fixing argument names in ReplaceWith of deprecated matchers (#341)
  • v3.1.4 Changes

    • ๐Ÿ›  Fix eventually nanos conversion (#340)
    • ๐Ÿ‘Œ Improve array shouldBe overloads (#339)
  • v3.1.3 Changes

    • โž• Added workaround for gradle 4.7/4.8 error #336
    • ๐Ÿ›  Fix URI path and URI parameter matchers (#338)
  • v3.1.2 Changes

    • โž• Added arrow NonEmptyList isUnique matchers
    • โž• Added Float and List Shrinker
    • โž• Added inspecting and extracting helper functions. (#334)
    • ๐Ÿ‘ Allow tags to be added to specs for all test cases #333
    • ๐Ÿ‘Œ Support randomized order of top level tests #328
  • v3.1.1 Changes

    • โœ… Focus option for top level tests #329
    • ๐Ÿ‘Œ Improve shrinkage #331
    • โšก๏ธ Updated readme for custom generators #313
    • โž• Added generator for UUIDs
    • ๐Ÿ›  Fixed bug with auto-close not being called. Deprecated ProjectExtension in favour of TestListener.
    • โž• Added a couple of edge case matchers to the arrow extension; added arrow matchers for lists.
  • v3.1.0 Changes

    • Simplified Setup

    ๐Ÿ‘• In KotlinTest 3.1.x it is sufficent to enable JUnit in the test block of your gradle build instead of using the gradle junit plugin. This step is the same as for any test framework that uses the JUnit Platform.

    โœ… Assuming you have gradle 4.6 or above, then setup your test block like this:

    test {

    โœ… You can additionally enable extra test logging:

    test {
        testLogging {
    • โœ… Instance Per Test for all Specs

    ๐Ÿ’… In the 3.0.x train, the ability to allow an instance per test was removed from some spec styles due to ๐Ÿ’… implementation difficulties. This has been addressed in 3.1.x and so all spec styles now allow instance ๐Ÿš€ per test as in the 2.0.x releases. Note: The default value is false, so tests will use a single shared โœ… instance of the spec for all tests unless the isInstancePerTest() function is overriden to return true.

    • ๐Ÿ’ฅ Breaking Change: Config Syntax

    โœ… The syntax for config has now changed. Instead of a function call after the test has been defined, it is โœ… now specified after the name of the test.

    So, instead of:

    "this is a test" {

    You would now do:

    "this is a test".config(...) {
    • Matchers as extension functions

    All matchers can now be used as extension functions. So instead of:

    file should exist()
    listOf(1, 2) should containNull()

    You can do:

    listOf(1, 2).shouldContainNull()

    Note: The infix style is not deprecated and will be supported in future releases, but the extension function ๐Ÿ’… is intended to be the preferred style moving forward as it allows discovery in the IDE.

    • Dozens of new Matchers

    even and odd

    โœ… Tests that an Int is even or odd:

    4 should beEven()
    3 shouldNot beEven()
    3 should beOdd()
    4 shouldNot beOdd()


    Asserts that an int or long is in the given range:

    3 should beInRange(1..10)
    4 should beInRange(1..3)


    Checks that a collection contains the given element at a specified index:

    listOf("a", "b", "c") should haveElementAt(1, "b")
    listOf("a", "b", "c") shouldNot haveElementAt(1, "c")

    Help out the type inferrer when using nulls:

    listOf("a", "b", null) should haveElementAt<String?>(2, null)

    readable, writeable, executable and hidden

    โœ… Tests if a file is readable, writeable, or hidden:

    file should beRadable()
    file should beWriteable()
    file should beExecutable()
    file should beHidden()

    absolute and relative

    โœ… Tests if a file's path is relative or absolute.

    File("/usr/home/sam") should beAbsolute()
    File("spark/bin") should beRelative()


    โœ… Tests if a file's path begins with the specified prefix:

    File("/usr/home/sam") should startWithPath("/usr/home")
    File("/usr/home/sam") shouldNot startWithPath("/var")


    Asserts that two objects have the same hash code.

    obj1 should haveSameHashCodeAs(obj2)
    "hello" shouldNot haveSameHashCodeAs("world")


    Asserts that two strings have the same length.

    "hello" should haveSameLengthAs("world")
    "hello" shouldNot haveSameLengthAs("you")

    haveScheme, havePort, haveHost, haveParameter, havePath, haveFragment

    Matchers for URIs:

    val uri = URI.create("https://localhost:443/index.html?q=findme#results")
    uri should haveScheme("https")
    uri should haveHost("localhost")
    uri should havePort(443)
    uri should havePath("/index.html")
    uri should haveParameter("q")
    uri should haveFragment("results")
    • Date matchers - before / after / haveSameYear / haveSameDay / haveSameMonth / within
    • Collections - containNull, containDuplicates
    • Futures - completed, cancelled
    • String - haveLineCount, contain(regex)
    • Types - haveAnnotation(class)

    • Arrow matcher module

    A new module has been added which includes matchers for Arrow - the popular and awesome functional programming library for Kotlin. To include this module add kotlintest-assertions-arrow to your build.

    The included matchers are:

    Option - Test that an Option has the given value or is a None. For example:

    val option = Option.pure("foo")
    option should beSome("foo")
    val none = None
    none should beNone()

    Either- Test that an Either is either a Right or Left. For example:

    Either.right("boo") should beRight("boo")
    Either.left("boo") should beLeft("boo")

    NonEmptyList- A collection (no pun intended) of matchers for Arrow's NonEmptyList. These mostly mirror the equivalent Collection matchers but for NELs. For example:

    NonEmptyList.of(1, 2, null).shouldContainNull()
    NonEmptyList.of(1, 2, 3, 4).shouldBeSorted<Int>()
    NonEmptyList.of(1, 2, 3, 3).shouldHaveDuplicates()
    NonEmptyList.of(1, 2, 3).shouldContain(2)
    NonEmptyList.of(1, 2, 3).shouldHaveSize(3)
    NonEmptyList.of(1, 2, 3).shouldContainNoNulls()
    NonEmptyList.of(null, null, null).shouldContainOnlyNulls()
    NonEmptyList.of(1, 2, 3, 4, 5).shouldContainAll(3, 2, 1)

    Try - Test that a Try is either Success or Failure.

    Try.Success("foo") should beSuccess("foo")
    Try.Failure<Nothing>(RuntimeException()) should beFailure()

    Validation - Asserts that a Validation is either Valid or an Invalid

    Valid("foo") should beValid()
    Invalid(RuntimeException()) should beInvalid()
    • Generator Bind

    A powerful way of generating random class instances from primitive generators is to use the new bind function. A simple example is to take a data class of two fields, and then use two base generators and bind them to create random values of that class.

    data class User(val email: String, val id: Int)
    val userGen = Gen.bind(Gen.string(), Gen.positiveIntegers(), ::User)
    assertAll(userGen) { shouldNotBe null should beGreaterThan(0)
    • โœ… Property Testing: Classify

    ๐Ÿ‘€ When using property testing, it can be useful to see the distribution of values generated, to ensure you're getting a good spread of values and not just trival ones. For example, you might want to run a test on a String and you want to ensure you're getting good amounts of strings with whitespace.

    To generate stats on the distribution, use classify with a predicate, a label if the predicate passes, and a label if the predicate fails. For example:

    assertAll(Gen.string()) { a ->
        classify(a.contains(" "), "has whitespace", "no whitespace")
        // some test

    And this will output something like:

    63.70% no whitespace
    36.30% has whitespace

    ๐Ÿ‘€ So we can see we're getting a good spread of both types of value.

    You don't have to include two labels if you just wish to tag the "true" case, and you can include more than one classification. For example:

    forAll( { a ->
        classify(a == 0, "zero")
        classify(a % 2 == 0, "even number", "odd number")
        a + a == 2 * a

    This will output something like:

    51.60% even number
    48.40% odd number
    0.10% zero
    • โœ… Property Testing: Shrinking

    • ๐Ÿท Tag Extensions

    A new type of extension has been added called TagExtension. Implementations can override the tags() function defined in this interface to dynamically return the Tag instances that should be active at any moment. The existing ๐Ÿ‘• system properties kotlintest.tags.include and kotlintest.tags.exclude are still valid and are not deprecated, but โž• adding this new extension means extended scope for more complicated logic at runtime.

    โœ… An example might be to disable any Hadoop tests when not running in an environment that doesn't have the hadoop home env variable set. After creating a TagExtension it must be registered with the project config.

    object Hadoop : Tag()
    object HadoopTagExtension : TagExtension {
      override fun tags(): Tags =
          if (System.getenv().containsKey("HADOOP_HOME")) Tags.include(Hadoop) else Tags.exclude(Hadoop)
    object MyProjectConfig : AbstractProjectConfig() {
      override fun extensions(): List<Extension> = listOf(HadoopTagExtension)
    object SimpleTest : StringSpec({
      "simple test" {
        // this test would only run on environments that have hadoop configured
      }.config(tags = setOf(Hadoop))
    • Discovery Extensions: instantiate()

    Inside the DiscoveryExtension interface the function fun <T : Spec> instantiate(clazz: KClass<T>): Spec? has been added which ๐Ÿ‘ allows you to extend the way new instances of Spec are created. By default, a no-args constructor is assumed. However, if this ๐Ÿ‘ function is overridden then it's possible to support Spec classes which have other constructors. For example, the Spring module ๐Ÿ‘ now supports constructor injection using this extension. Other use cases might be when you want to always inject some config class, โœ… or if you want to ensure that all your tests extend some custom interface or superclass.

    As a reminder, DiscoveryExtension instances are added to Project config.

    • System out / error extensions

    โœ… An extension that allows you to test for a function that writes to System.out or System.err. To use this extension add the module kotlintest-extensions-system to your build.

    By adding the NoSystemOutListener or NoSystemErrListener to your config or spec classes, anytime a function tries to write to either of these streams, a SystemOutWriteException or SystemErrWriteException will be raised with the string that the function tried to write. This allows you to test for the exception in your code.

    For example:

    class NoSystemOutOrErrTest : StringSpec() {
      override fun listeners() = listOf(NoSystemOutListener, NoSystemErrListener)
      init {
        "System.out should throw an exception when the listener is added" {
          shouldThrow<SystemOutWriteException> {
          }.str shouldBe "boom"
        "System.err should throw an exception when the listener is added" {
          shouldThrow<SystemErrWriteException> {
          }.str shouldBe "boom"
    • System.exit extension

    ๐Ÿ‘• Another extension that is part of the kotlintest-extensions-system module. This extension will allow you to test if System.exit(Int) is invoked in a function. It achieves this by intercepting any calls to System.exit and instead of terminating the JVM, it will throw a SystemExitException with the exit code.

    For example:

    class SystemExitTest : StringSpec() {
      override fun listeners() = listOf(SpecSystemExitListener)
      init {
        "System.exit should throw an exception when the listener is added" {
          shouldThrow<SystemExitException> {
          }.exitCode shouldBe 123
    • โšก๏ธ Spring Module Updates

    โšก๏ธ The spring extension module kotlintest-extensions-spring has been updated to allow for constructor injection. This new extension is called SpringAutowireConstructorExtension and must be added to your `ProjectConfig. โœ… Then you can use injected dependencies directly in the primary constructor of your test class.

    For example:

    @ContextConfiguration(classes = [(Components::class)])
    class SpringAutowiredConstructorTest(service: UserService) : WordSpec({
      "SpringListener" should {
        "have autowired the service" {
          service.repository.findUser().name shouldBe "system_user"
    • JUnit 4 Runner

    ๐Ÿ‘• A JUnit 4 runner has been added which allows KotlinTest to run using the legacy JUnit 4 platform. ๐Ÿ‘• To use this, add kotlintest-runner-junit4 to your build instead of kotlintest-runner-junit5.

    Note: This is intended for use when junit5 cannot be used. It should not be the first choice as functionality is restricted.


    • โœ… In intellij, test output will not be nested
    • ๐Ÿ‘ Project wide beforeAll/afterAll cannot be supported.
  • v3.0.x Changes

    March 29, 2018
    • Module split out

    ๐Ÿ‘• KotlinTest has been split into multiple modules. These include core, assertions, the junit runner, and extensions such as spring, allure and junit-xml.

    ๐Ÿš€ The idea is that in a future release, further runners could be added (TestNG) or for JS support (once multi-platform Kotlin is out of beta). โฌ†๏ธ When upgrading you will typically want to add the kotlintest-core, kotlintest-assertions and kotlintest-runner-junit5 to your build โšก๏ธ rather than the old kotlintest module which is now defunct. When upgrading, you might find that you need to update imports to some matchers.

    testCompile 'io.kotlintest:kotlintest-core:3.0.0'
    testCompile 'io.kotlintest:kotlintest-assertions:3.0.0'
    testCompile 'io.kotlintest:kotlintest-runner-junit5:3.0.0'

    Gradle Users:

    Also you must include apply plugin: 'org.junit.platform.gradle.plugin' in your project and ๐Ÿ— classpath "org.junit.platform:junit-platform-gradle-plugin:1.1.0" to the dependencies section of your buildscript โœ… or tests will not run (or worse, will hang). This allows gradle to execute jUnit-platform-5 based tests (which KotlinTest builds upon). Note: Gradle says that this is not required as of 4.6 but even ๐Ÿ‘€ with 4.6 it seems to be required.

    Maven users:

    ๐Ÿ”Œ You need to include the following in your plugins:


    And you must include


    as a regular dependency.

    • ๐Ÿ’ฅ Breaking: ProjectConfig

    ๐Ÿ‘• Project wide config in KotlinTest is controlled by implementing a subclass of AbstractProjectConfig. In previous versions you could ๐Ÿ‘• call this what you wanted, and place it where you wanted, and KotlinTest would attempt to find it and use it. This was the cause of ๐Ÿ‘• many bug reports about project start up times and reflection errors. So in version 3.0.x onwards, KotlinTest will no longer attempt to scan the classpath.

    ๐Ÿ‘• Instead you must call this class ProjectConfig and place it in a package io.kotlintest.provided. It must still be a subclass of ๐Ÿ‘• AbstractProjectConfig This means kotlintest can do a simple Class.forName to find it, and so there is no startup penalty nor reflection issues.

    Project config now allows you to register multiple types of extensions and listeners, as well as setting parallelism.

    • ๐Ÿ’ฅ Breaking: Interceptors have been deprecated and replaced with Listeners

    โœ… The previous inteceptors were sometimes confusing. You had to invoke the continuation function or the spec/test โœ… would not execute. Not invoking the function didn't mean the spec/test was skipped, but that it would hang.

    ๐Ÿšš So interceptors are deprecated, and in some places removed. Those are not removed are now located in classes called ๐Ÿ‘€ SpecExtension and TestCaseExtension and those interfaces should be used rather than functions directly.

    Here is an example of a migrated interceptor.

    val mySpecExtension = object : SpecExtension {
        override fun intercept(spec: Spec, process: () -> Unit) {
          println("Before spec!")
          println("After spec!")

    ๐Ÿ’… As a replacement, in 3.0.0 we've added the TestListener interface which is the more traditional before/after style callbacks. โœ… In addition, these methods include the result of the test (success, fail, error, skipped) which gives you more โœ… context in writing plugins. The TestListener interface offers everything the old interceptors could do, and more.

    Here is an example of a simple listener.

    object TimeTracker : TestListener {
      var started = 0L
      override fun beforeTest(description: Description) {
        TimeTrackerTest.started = System.currentTimeMillis()
      override fun afterTest(description: Description, result: TestResult) {
        val duration = System.currentTimeMillis() - TimeTrackerTest.started
        println("Test ${description.fullName()} took ${duration}ms")

    If you want to use these methods in a Spec itself, then you can just override the functions directly because a Spec is already a TestListener.

    object TimeTracker : WordSpec() {
      var started = 0L
      override fun beforeTest(description: Description) {
        started = System.currentTimeMillis()
      override fun afterTest(description: Description, result: TestResult) {
        val duration = System.currentTimeMillis() - started
        println("Test ${description.fullName()} took ${duration}ms")
      init {
        "some test" should {
          "be timed" {
            // test here

    Listeners can be added project wide by overriding listeners() in the ProjectConfig.

    ๐Ÿš€ Note: In the next release, new Extension functions will be added which will be similar to the old interceptors, but with complete control over the lifecycle. For instance, a future intercept method will enforce that the user skip, run or abort a test in the around advice. They will be more complex, and so suited to more advanced use cases. The new TestListener interface will remain of course, and is the preferred option.

    • Parallelism

    If you want to run more than one spec class in parallel, you can by overriding parallelism inside your projects ๐Ÿ‘• ProjectConfig or by supplying the system property kotlintest.parallelism.

    Note the system property always takes precedence over the config.

    • ๐Ÿ‘ Futures Support

    โœ… Test cases now support waiting on futures in a neat way. If you have a value in a CompletableFuture that you want โœ… to test against once it completes, then you can do this like this:

    val stringFuture: CompletableFuture<String> = ...
    "My future test" should {
      "support CompletableFuture<T>" {
        whenReady(stringFuture) {
          it shouldBe "wibble"
    • ๐Ÿ’ฅ Breaking: Exception Matcher Changes

    โœ… The shouldThrow<T> method has been changed to also test for subclasses. For example, shouldThrow<IOException> will also match ๐Ÿ‘• exceptions of type FileNotFoundException. This is different to the behavior in all previous KotlinTest versions. If you wish to โœ… have functionality as before - testing exactly for that type - then you can use the newly added shouldThrowExactly<T>.

    • JUnit XML Module

    ๐Ÿ‘Œ Support for writing out reports in junit-format XML has added via the kotlintest-extensions-junitxml module which you will need to add to your build. This module โœ… provides a JUnitXmlListener which you can register with your project to autowire your tests. You can register this by overriding listeners() in ProjectConfig.

    class ProjectConfig : AbstractProjectConfig() {
        override fun listeners() = listOf(JUnitXmlListener)
    • Spring Module

    ๐Ÿ‘• Spring support has been added via the kotlintest-extensions-spring module which you will need to add to your build. This module โœ… provides a SpringListener which you can register with your project to autowire your tests. You can register this for just some classes by overriding the listeners() function inside your spec, for example:

    class MySpec : ParentSpec() {
        override fun listeners() = listOf(SpringListener)

    Or you can register this for all classes by adding it to the ProjectConfig. See the section on ProjectConfig for how to do this.

    • ๐Ÿ’ฅ Breaking: Tag System Property Rename

    ๐Ÿ‘• The system property used to include/exclude tags has been renamed to kotlintest.tags.include and kotlintest.tags.exclude. Make โšก๏ธ sure you update your build jobs to set the right properties as the old ones no longer have any effect. If the old tags are detected โš  then a warning message will be emitted on startup.

    • ๐Ÿ†• New Matchers

    โœ… beInstanceOf<T> has been added to easily test that a class is an instance of T. This is in addition to the more verbose beInstanceOf(SomeType::class).

    The following matchers have been added for maps: containAll, haveKeys, haveValues. These will output helpful error messages showing you which keys/values or entries were missing.

    ๐Ÿ†• New matchers added for Strings: haveSameLengthAs(other), beEmpty(), beBlank(), containOnlyDigits(), containADigit(), containIgnoringCase(substring), lowerCase(), upperCase().

    ๐Ÿ†• New matchers for URIs: haveHost(hostname), havePort(port), haveScheme(scheme).

    ๐Ÿ†• New matchers for collections: containNoNulls(), containOnlyNulls()

    • ๐Ÿ’ฅ Breaking: One instance per test changes

    One instance per test is no longer supported for specs which offer nested scopes. For example, WordSpec. This is because of the tricky โœ… nature of having nested closures work across fresh instances of the spec. When using one instance per test, a fresh spec class is required โœ… for each test, but that means selectively executing some closures and not others in order to ensure the correct state. This has proved the largest source of bugs in previous versions.

    ๐Ÿ‘• KotlinTest 3.0.x takes a simplified approach. If you want the flexibilty to lay out your tests with nested scopes, then all tests will โœ… execute in the same instance (like Spek and ScalaTest). If you want each test to have it's own instance (like jUnit) then you can either โœ… split up your tests into multiple files, or use a "flat" spec like FunSpec or StringSpec.

    This keeps the implementation an order of magnitude simplier (and therefore less likely to lead to bugs) while offering a pragmatic approach to keeping both sets of fans happy.

    • ๐Ÿ†• New Specs

    Multiple new specs have been added. These are: AnnotationSpec, DescribeSpec and ExpectSpec. Expect spec allows you to use the context โœ… and expect keywords in your tests, like so:

    class ExpectSpecExample : ExpectSpec() {
      init {
        context("some context") {
          expect("some test") {
            // test here
          context("nested context even") {
            expect("some test") {
              // test here

    ๐Ÿ‘• The AnnotationSpec offers functionality to mimic jUnit, in that tests are simply functions annotated with @io.kotlintest.specs.Test. For example:

    class AnnotationSpecExample : AnnotationSpec() {
      fun test1() {
      fun test2() {

    And finally, the DescribeSpec is similar to SpekFramework, using describe, and, and it. This makes it very useful for those people who are looking ๐Ÿ‘• to migrate to KotlinTest from SpekFramework.

    class DescribeSpecExample : DescribeSpec() {
      init {
        describe("some context") {
          it("test name") {
            // test here
          describe("nested contexts") {
            and("another context") {
              it("test name") {
                // test here
    • โœ… Property Testing with Matchers

    โœ… The ability to use matchers in property testing has been added. Previously property testing worked only with functions that returned a Boolean, like:

    "startsWith" {
      forAll(Gen.string(), Gen.string(), { a, b ->
        (a + b).startsWith(a)

    But now you can use assertAll and assertNone and then use regular matchers inside the block. For example:

    "startsWith" {
      assertAll(Gen.string(), Gen.string(), { a, b ->
        a + b should startWith(a)

    This gives you the ability to use multiple matchers inside the same block, and not have to worry about combining all possible errors into a single boolean result.

    • Generator Edge Cases

    Staying with property testing - the Generator interface has been changed to now provide two types of data.

    The first are values that should always be included - those edge cases values which are common sources of bugs. For example, a generator for Ints should always include values like zero, minus 1, positive 1, Integer.MAX_VALUE and Integer.MIN_VALUE. Another example would be for a generator for enums. That should include all the values of the enum to ensure โœ… each value is tested.

    โœ… The second set of values are random values, which are used to give us a greater breadth of values tested. The Int generator should return random ints from across the entire integer range.

    ๐Ÿ‘€ Previously generators used by property testing would only include random values, which meant you were very unlikely to see the edge cases that usually cause issues - like the aforementioned Integer MAX / MIN. Now you are guaranteed to get the edge cases first and the random values afterwards.

    • ๐Ÿ’ฅ Breaking: MockitoSugar removed

    ๐Ÿคก This interface added a couple of helpers for Mockito, and was used primarily before Kotlin specific mocking libraries appeared. ๐Ÿ— Now there is little value in this mini-wrapper so it was removed. Simply add whatever mocking library you like to your build and use it as normal.

    • CsvDataSource

    โœ… This class has been added for loading data for table testing. A simple example:

    class CsvDataSourceTest : WordSpec() {
      init {
        "CsvDataSource" should {
          "read data from csv file" {
            val source = CsvDataSource(javaClass.getResourceAsStream("/user_data.csv"), CsvFormat())
            val table = source.createTable<Long, String, String>(
                { it: Record -> Row3(it.getLong("id"), it.getString("name"), it.getString("location")) },
                { it: Array<String> -> Headers3(it[0], it[1], it[2]) }
            forAll(table) { a, b, c ->
              a shouldBe gt(0)
              b shouldNotBe null
              c shouldNotBe null
    • Matcher Negation Errors

    ๐Ÿ‘ All matchers now have the ability to report a better error when used with shouldNot and shouldNotBe. Previously a generic error was generated - which was usually the normal error but with a prefix like "NOT:" but now each built in matcher will provide a full message, for example: Collection should not contain element 'foo'