Regarding your first question, it's possible to co...
# kotlintest
l
Regarding your first question, it's possible to compose scenarios and reutilize code for many similar scenarios, however. While writing a test that will display the same thing. With your example I might know how I'd solve it
r
Thanks for your quick reply. Following an example of a specific spec which uses a generic spec (I use Spek currently): https://github.com/robstoll/atrium/blob/master/apis/cc-infix-en_GB/atrium-api-cc-infix-en_GB-jvm/src/test/kotlin/ch/tutteli/atrium/api/cc/infix/en_GB/IterableContainsInAnyOrderAtLeast1EntriesAssertionsSpec.kt Regarding
finding tests
phase, I guess you have one but probably name it differently. Say you get a AccessDeniedException when accessing a test. This does not have to do anything with the test itself but with the infrastructure (e.g. your CI). JUnit5 would say it's all fine per default, that's why I wonder. Regarding multi-platform, that would have been a killer argument for me. In this case I'll stick to Spek for the moment. Thanks for your time
l
I don't know if I actually understood that scenario. If anything is uncaught while the engine is executing, you should presume the test will fail.
r
๐Ÿ‘ that's how it should be IMO, really annoying that this is not the default in the JUnit5 platform. I guess you are not relying on JUnit then, right?
l
We are relying on JUnit, but this kind of thing was never a problem to us
Maybe it's because we are the ones that execute all the tests, we don't use JUnit for the execution
r
It's a "feature" of the ConsoleRunner (or a similar name) of JUnit, as long as you don't use it then you should be save
l
I didn't exactly understand that spec you sent, but composing specs in that way is currently unsupported. You can reutilize code in other ways, but saying
This class  should pass these tests from another class
is not yet supported
Let me investigate your test a little more to see how I would do it in Kotlintest
r
ch.tutteli.atrium.spec.integration.IterableContainsInAnyOrderAtLeast1EntriesAssertionsSpec
defines the spec as such and requires certain functions which the BuilderSpec and the ShortcutSpec provide
and the generic spec itself uses two other generics specs
I am looking forward to how you would do it in kotlintest ๐Ÿ™‚
l
Is there a scenario you'd consider simpler? What would be a hello world to this behavior?
If you want to see how this exact scenario works, I'll need some more time hahaha
r
I would say the strategy pattern. Say you have Strategy A, B and C all implementing MyStrategy. Ideally you only need to write one spec and all strategies can reuse it
For instance, the strategy is counting letters. No matter how the concrete strategies are implemented when counting
l
in "hello world" then all should come up with
3
as result. Do you see what I mean?
l
I see
r
the only difference is that I am using function types instead of own interfaces in the generic spec
l
A dumbed down version of this, would be something like
Copy code
interface SumCalculator {
  fun add(first: Int, second: Int): Int
}

interface SubtractionCalculator {
  fun subtract(first: Int, second: Int): Int
}

class SumOnlyCalculator : SumCalculator {
  override fun add(first: Int, second: Int): Int = first + second
}

class ComplexCalculator : SumCalculator, SubtractionCalculator {
  override fun add(first: Int, second: Int): Int = first + second
  override fun subtract(first: Int, second: Int): Int = first - second
}
Textbook example, but... hahaha
And I'd like to only add one test for
ComplexCalculator
and
SumOnlyCalculator
, right?
And make them reuse it
(The same would go for ComplexCalculator and SubtractOnlyCalculator)
r
exactly
l
Good. Let me see what I'd do to that.
The obvious inneficient alternative would be to rewrite the
sum
test twice
and the
subtract
test twice
r
clearly not ideal... I'll let you ponder ๐Ÿ™‚
l
Ok. As I said, this is not really supported yet.
But for this stupid hello world example, one could do something like this:
Copy code
fun AbstractStringSpec.testSumCalculations(sumCalculator: SumCalculator) {
  "should sum correctly" {
    sumCalculator.add(1, 2) shouldBe 3
  }
}

fun AbstractStringSpec.testSubtractCalculations(subtractionCalculator: SubtractionCalculator) {
  "should subtract correctly" {
    subtractionCalculator.subtract(2, 1) shouldBe 1
  }
}

class SumOnlyCalculatorTest : StringSpec({
  testSumCalculations(SumOnlyCalculator())
})

class SubtractOnlyCalculatorTest : StringSpec({
  testSubtractCalculations(SubtractionOnlyCalculator())
})

class ComplexCalculatorTest : StringSpec({
  val target = ComplexCalculator()

  testSumCalculations(target)
  testSubtractCalculations(target)

})
I admit it's not a good solution
I wouldn't even call it a solution, but I'm trying to show that it's possible to reuse code to create tests
You could create a dsl somewhat like this to enable test sharing
We probably will do something similar to that in the future. Probably for 3.3 (KT is currently at version 3.2.1)
Our concept of spec sharing is still pretty raw, and we don't know how we want to design it yet. If you'd like to drop us a feature request ๐Ÿ™‚
r
if its of value for you then I will open an issue with the strategy example.
l
It would be, yes
I personally don't use it a lot, so I wouldn't know how you would want to
r
๐Ÿ‘๐Ÿป 1
something to start with I hope. I cannot propose dsl etc. because I don't use kotlintest.
l
Thanks a lot for opening the issue!
We should take the discussion there, ok?
Thanks very much in showing interest and giving me examples! I now understand a little bit better what people that ask this feature want
r
You're welcome, thanks for your time ๐Ÿ™‚