1

I currently use junit5, wiremock and restassured for my integration tests. Karate looks very promising, yet I am struggling with the setup of data-driven tests a bit as I need to prepare a nested data structures which, in the current setup, looks like the following: 

abstract class StationRequests(val stations: Collection<String>): ArgumentsProvider {
    override fun provideArguments(context: ExtensionContext): java.util.stream.Stream<out Arguments>{
        val now = LocalDateTime.now()
        val samples = mutableListOf<Arguments>()

        stations.forEach { station ->
            Subscription.values().forEach { subscription ->
                listOf(
                    *Device.values(),
                    null 
                ).forEach { device ->
                    Stream.Protocol.values().forEach { protocol ->
                        listOf(
                            null,
                            now.minusMinutes(5),
                            now.minusHours(2),
                            now.minusDays(1)
                        ).forEach { startTime ->
                            samples.add(
                                Arguments.of(
                                    subscription, device, station, protocol, startTime
                                )
                            )
                        }
                    }
                }
            }
        }
        return java.util.stream.Stream.of(*samples.toTypedArray())
    }
}

Is there any preferred way how to setup such nested data structures with karate? I initially thought about defining 5 different arrays with sample values for subscription, device, station, protocol and startTime and to combine and merge them into a single array which would be used in the Examples: section.

I did not succeed so far though and I am wondering if there is a better way to prepare such nested data driven tests?

u6f6o
  • 2,050
  • 3
  • 29
  • 54

1 Answers1

1

I don't recommend nesting unless absolutely necessary. You may be able to "flatten" your permutations into a single table, something like this: https://github.com/intuit/karate/issues/661#issue-402624580

That said, look out for the alternate option to Examples: which just might work for your case: https://github.com/intuit/karate#data-driven-features

EDIT: In version 1.3.0, a new @setup life cycle was introduced that changes the example below a bit.

Here's a simple example:

Feature:

Scenario:
* def data = [{ rows: [{a: 1},{a: 2}] }, { rows: [{a: 3},{a: 4}] }]
* call read('called.feature@one') data

and this is: called.feature:

@ignore
Feature:

@one
Scenario:
* print 'one:', __loop
* call read('called.feature@two') rows

@two
Scenario:
* print 'two:', __loop
* print 'value of a:', a

This is how it looks like in the new HTML report (which is in 0.9.6.RC2 and may need more fine tuning) and it shows off how Karate can support "nesting" even in the report, which Cucumber cannot do. Maybe you can provide feedback and let us know if it is ready for release :)

enter image description here

Peter Thomas
  • 54,465
  • 21
  • 84
  • 248
  • thanks for the quick response! Could you explain, why I should avoid nested structures in tests if possible? – u6f6o May 09 '20 at 10:42
  • @u6f6o purely for maintainability, you can see how even the above simple example blew up at run-time. but maybe you do genuinely have a need to do this, and I personally feel (biased opinion) Karate is suited for even unit-testing, so go for it ! https://twitter.com/KarateDSL/status/1184450203614498817 – Peter Thomas May 09 '20 at 10:47
  • 1
    I had a look at the requested sources and figured out how to make it work. I agree with your point regards maintainability though and decided to split up the big data driven test into separate features. Not done yet, but first draft looks promising ;-) – u6f6o May 11 '20 at 08:06