aspen alternatives and similar libraries
Based on the "Tests" category.
Alternatively, view aspen alternatives based on common mentions on social networks and blogs.
-
Kotest
Powerful, elegant and flexible test framework for Kotlin with additional assertions, property testing and data driven testing -
kotlin-faker
https://serpro69.github.io/kotlin-faker/ Generate realistically looking fake data such as names, addresses, banking details, and many more, that can be used for testing and data anonymization purposes. -
hikaku
A library that tests if the implementation of a REST-API meets its specification. -
balin
Balin is an automation library for Kotlin. It's basically a Selenium-WebDriver wrapper inspired by Geb. -
SeleniumBuilder
Kotlin DSL for Selenium. Provide a possibility to write tests in Kotlin type-safe builders style -
arbitrater
Arbitrater is a Kotlin library for creating arbitrary instances of classes by reflection for use in testing. In contrast to POJO generators, it supports Kotlin's optional parameters and nullable types. -
DynaTest
Simplest & Powerful Testing Framework For Kotlin. No annotations! -
mock-fuel
JUnit 5 extension to easily test with the http client Fuel for Kotlin
WorkOS - The modern identity platform for B2B SaaS
Do you think we are missing an alternative of aspen or a related project?
Popular Comparisons
README
Aspen is a JUnit runner for Kotlin. It's inspired by Ruby's RSpec syntax, the default DSL has a lot more restrictions but you can create your own DSL if it does not fit your needs.
Gradle usage
Aspen
testCompile "io.damo.aspen:aspen:<version>"
Aspen Spring
testCompile "io.damo.aspen:aspen-spring:<version>"
You will need to use jCenter maven repository
repositories {
jcenter()
}
Example
If you were to use AssertJ for assertions.
class CompanyControllerTest: Test({
val mockRepo = mock(CompanyRepository::class.java)
val controller = CompanyController(mockRepo)
useRule(MyAwesomeRule())
before {
reset(mockRepo)
}
describe("#create") {
test {
val company = Company(name = "Wayne Enterprises")
doReturn(company).upon(mockRepo).create(any())
val response = controller.create("Wayne Ent.")
assertThat(response).isEqualTo(Response(company, true))
verify(mockRepo).create("Wayne Ent.")
}
test("repository creation error") {
doReturn(null).upon(mockRepo).create(any())
val response = controller.create("Wayne Ent.")
assertThat(response).isEqualTo(Response(null as Company?, false))
}
}
})
You can focus a test by prefixing changing test
to ftest
. Then only this or these tests get run.
For example running the tests above after replacing the second test with
ftest("repository creation error") {
doReturn(null).upon(mockRepo).create(anyString())
val response = controller.create("Wayne Ent.")
assertThat(response).isEqualTo(Response(null as Company?, false))
}
Only that second test will get run.
Writing table based tests (a.k.a. Parameterized tests) can be as simple as the following
class ReservationTestExample : Test({
describe("#amount") {
class AmountData
(name: String, val status: Status, val amount: Int) : TestData(name)
val data = listOf(
AmountData("when status is OPEN", Status.OPEN, 0),
AmountData("when status is STARTED", Status.STARTED, 0),
AmountData("when status is BILLED", Status.BILLED, 100),
AmountData("when status is PAID", Status.PAID, 100)
)
tableTest(data) {
assertThat(Reservation(status).amount()).isEqualTo(amount)
}
}
})
Restrictions
There can only be one before
block and it has to be at the top level.
describe
blocks can only contain test
blocks and they cannot be nested further.
Unlike RSpec, there are no it
blocks. We are trying to encourage having expressive assertions
that should describe correctly your expectations.
Why all these restrictions?
The goal of this library is to make your tests a little easier to organize. But we do believe that the JUnit style is sufficient for testing and encourages making your test code clear and easy to read, so we are not adding any unnecessary complexity.
But I want my own DSL!
We tried to make custom Domain Specific Languages easy to write. You can see an example of a second DSL we created allowing nesting by following these links:
Spring Support
Aspen supports Spring!
@RunWith(SpringTestTreeRunner::class)
@SpringApplicationConfiguration(ExampleApplication::class)
@WebIntegrationTest("server.port:0")
class SpringApplicationTest : Test({
val message: String = inject("myMessage")
val port = injectValue("local.server.port", Int::class)
val client = OkHttpClient()
test("GET /hello") {
val request = Request.Builder()
.url("http://localhost:$port/hello")
.build()
val response = client.newCall(request).execute()
val body = response.body().string()
assertThat(body).isEqualTo("""{"hello":"$message"}""")
}
})
More examples
You will find actually up-to-date examples that are part of our test suite in the following locations:
Blog posts
What's next?
We have a Pivotal Tracker project, see for yourself