At Avisi we have been using SoapUI since forever to automate our webservice tests. In early days we only had SOAP-services to test (because we had enterprisey reasons), later REST-services as wel. Automating tests for them has mainly been the tester’s concern and as such, the tester has always been choosing the test automation tooling. Often, this tooling isn’t very programmer-friendly:

  • Test suites are often maintained using clunky and buggy grapical interfaces.
  • Projects are often one big file, leading to a number of problems: it makes source control slow, diff-tools are often not usable. Collaboration is not possible or very limited.
  • Extending is problematic or impossible. API’s are either legacy or you’re relying on the vendor to implement the features you’re missing, which will cost you.

Most of the members in my teams1 are developers, who also write tests for the stuff the build. From that perspective, it’s pretty strange that our automated test tooling is largely aimed at the testers instead of developers. We don’t want our testers to be concerned with automation, we want them to be concerned with thinking up new test cases and finding bugs. Automation is a developer’s forte.

That’s where Kotlin Webtest comes into play. It allows developers to write maintainable webservice tests in a code-centric way using a DSL (Domain Specific Language). Since it’s Just A LibraryTM, it will fit seamlessly into your existing Java/Kotlin/Groovy/Scala/Whatever build.

Features

  • Lightweight: there’s no stuff you’re not going to use
  • Blazingly fast, because it’s so simple
  • JUnit support
  • SOAP (1.1, 1.2, SwA, MTOM)
  • REST
  • Authentication
  • Good maintainability and re-use through templating and variable interpolation
  • Validators: JDBC, JSON, XPath, HTTP, XSD, and more
  • It’s code-centric so allows you to use any Kotlin/Java feature or library out there

Example

A typical REST test can look like this:

    
class PetStoreDslTest : WebTest() {

    override fun configure() {
        rest {
            default {
                request endpoint Endpoint("Pet store", "http://petstore")
            }
        }
    }

    @Test
    fun testBuyCat() {
        test("Buy Cat") {
            step rest {
                name = "List pets"
                request method GET
                request path "/pet"
                validate {
                    http_status() matches 200
                    http_header("Content-Type") matches "application/json"
                    json_path("$[0].type") matches "Cat"
                }
                afterwards {
                    assign property "petId" from json_path("$[0].id")
                }
            }
            step rest {
                name = "Buy pet"
                request method POST
                request path "/pet/#{petId}?action=buy"
                validate {
                    http_status() matches 201
                }
            }
        }
        execute()
    }
}

Benefits

For us, the benefits are clear. Since we’ve started using Kotlin Webtest:

  • Writing tests takes less time since there’s no need to use a clunky, buggy UI.
  • Test execution time is now hardly 1/4th of what it was before.
  • Integration in IDEs and CI-systems is ‘free’, since we’re just running unit tests.
  • We can collaborate writing tests, since it’s just ‘regular’ code.

At Avisi we use the DSL, bootstrapped using JUnit, but there is no reason why you can’t use another unit testing framework. You could even leave the DSL for what it is and just use the testing core. Maybe you want to write Gherkin/Cucumber tests on top of it?

We’re continually adding features and making it more usable to all of you out there. Want to give it a try? Find us on Github: https://github.com/avisi/kotlin-webtest.

  • 1 I’m employed by Avisi as Technical Lead.