为该TDD-way代码组织测试的正确方法是什么?

时间:2020-08-06 18:26:45

标签: unit-testing testing tdd

例如一个leetcode问题有以下测试或示例:

Input: pattern = "abba", str = "dog cat cat dog"
Output: true
Example 2:

Input:pattern = "abba", str = "dog cat cat fish"
Output: false
Example 3:

Input: pattern = "aaaa", str = "dog cat cat dog"
Output: false
Example 4:

Input: pattern = "abba", str = "dog dog dog dog"
Output: false

我编写了函数f,现在需要使用上面的示例对其进行测试:

pattern = "abba"
s = "dog dog dog dog"

pattern = "abba"
s = "dog cat cat dog"

pattern = "abba"
s = "dog cat cat fish"

pattern = "aaaa"
s = "dog cat cat dog"

pattern = "abba"
s = "dog dog dog dog"

我可以简单地写断言语句:

assert( f(pattern,s)) == False 

但是使用测试驱动的开发方法编写测试的另一种“正确方法”是什么?

1 个答案:

答案 0 :(得分:0)

使用测试驱动的开发方法

“按书”方法看起来像

  1. 创建一个清单,并向其中添加少量测试思路。列表不必特别长-四个就足够了-您可以不断添加想法。

  2. 从“小”测试中选择一个开始

  3. 实施该测试

3a)添加获得要编译的测试所需的生产代码 3b)添加所需的生产代码以得到“正确的”错误答案

  1. 实施足够的代码以通过测试;通常您是在这里优化挂钟时间,所以通常这意味着硬编码正确的答案。

  2. “重构”生产代码-也就是说,在进行小的改进和重新运行测试之间进行循环,直到您对仅支持该测试的代码质量感到满意为止。

  3. 选择您的下一个测试,然后重复步骤3-6,直到检查表上的所有项目都完成。

assert( f("abba","dog cat cat fish")) == False 

是的-很好。根据当地惯例,您可能更喜欢

assert ! f("abba","dog cat cat fish")

测试(例如生产代码)可以从设计中受益,因此,您需要考虑想要测试代码具有什么特征(除了告诉机器要做什么)。

相关问题