【问题标题】:How to prepare a nested data structure for a data-driven test in Karate?如何为空手道中的数据驱动测试准备嵌套数据结构?
【发布时间】:2020-05-08 17:26:55
【问题描述】:

我目前使用 junit5、wiremock 和 reassured 进行集成测试。空手道看起来很有前途,但我在数据驱动测试的设置方面有点挣扎,因为我需要准备一个嵌套数据结构,在当前设置中,它看起来如下所示:

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())
    }
}

有没有什么首选的方法可以用空手道设置这种嵌套的数据结构?我最初考虑定义 5 个不同的数组,其中包含订阅、设备、站点、协议和 startTime 的样本值,并将它们组合并合并到一个数组中,该数组将在Examples: 部分中使用。

到目前为止我还没有成功,我想知道是否有更好的方法来准备这种嵌套的数据驱动测试?

【问题讨论】:

    标签: testing integration-testing karate junit5


    【解决方案1】:

    除非绝对必要,否则我不建议嵌套。您也许可以将排列“扁平化”到一个表中,如下所示:https://github.com/intuit/karate/issues/661#issue-402624580

    也就是说,请注意Examples: 的替代选项,它可能适用于您的情况:https://github.com/intuit/karate#data-driven-features

    这是一个简单的例子:

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

    这是: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
    

    这就是它在new HTML report 中的样子(它在 0.9.6.RC2 中,可能需要更多微调),它展示了即使在报告中空手道也可以支持“嵌套”,这是 Cucumber 无法做到的.也许您可以提供反馈并让我们知道它是否已准备好发布:)

    【讨论】:

    • 感谢您的快速响应!你能解释一下,为什么我应该尽可能避免在测试中使用嵌套结构?
    • @u6f6o 纯粹是为了可维护性,您可以看到即使是上面的简单示例在运行时也会崩溃。但也许你真的需要这样做,我个人认为(有偏见的意见)空手道甚至适合单元测试,所以去吧! twitter.com/KarateDSL/status/1184450203614498817
    • 我查看了请求的来源并弄清楚了如何使其工作。不过,我同意您关于可维护性的观点,并决定将大数据驱动的测试拆分为单独的功能。尚未完成,但初稿看起来很有希望 ;-)
    猜你喜欢
    • 2012-08-25
    • 2020-10-08
    • 1970-01-01
    • 2014-07-06
    • 2020-10-21
    • 2021-09-26
    • 1970-01-01
    • 1970-01-01
    • 2023-04-09
    相关资源
    最近更新 更多