fizzbuzz牛津英语树 fizzbuzz( 七 ) _生活百科

一个场景告诉我们，fizzbuzz故事，即便是一个测试用例，从入口进去，从出口出来，也不表示他测的是整个逻辑，是更多的关注了其中的一部分逻辑。
这就好像绘本照相的时候一样。即便整个景色都被我照了下来，但是我的一张照片总有一个聚焦的焦点，这个地方会特别的清楚。测试也是一样。如下图所示：

文章插图

文章插图
所以我们看待测试用例的时候不能一视同仁。这种虽然是端到端的测试数据，但实际上只关注部分逻辑的思路，在系统重构的时候有更多的使用场景。
一般等价类从这个场景下我们也可以发现，如果仅写一个输入的值在测试用例的名字上，我们是不知道这个测试用例在测什么中文的。
测试代码也是代码，也要追求可读性。
所以比起之前写音标3或者现在写6，fizzbuzz是什么意思啊。用一个更具有表义性的词来称呼会更好，比如像下面这样：
这种更具有表义性的词，我们称之为一般等价类。我们写测试的时候会发现，测试数据经常是无穷无尽的，难道我无穷无尽的测下去吗？肯定是不行的。但是我还是希望能够测的尽量全一点。我测了哪些东西之后，就可以认为我测的比较全了呢，如何来得到一个性价比较高的测试用例集合呢。这时候我们要做一般等价类的分析，在我们这个题里面大概有下面几个等价类：被3整除，被5整除，被7整除，包含3，包含5，包含7 。只要是一类的数据，我们只需要一个数据就算是覆盖了这一类的情况。这一类就叫一般等价类，所以我们改完后的代码应该是下面这样的：

文章插图
执行了之后就能看到这个：

文章插图
我们经常讲敏捷是工作的软件胜过面面俱到的文档。这并不是说我们不写文档，而是说我们的文档也是一种可以工作的软件。就像这个测试一样，fizzbuzz音标。我们称之为测试即文档，也叫活的文档。代码同样，也叫代码即文档。所以我们前面讲测试也要追求可读性。实际上测试的可能性比实现代码的可能性要求还要高一些。不过通常来讲也是有一些套路可循的。
首先我们看名字，should开头，表示输出，given表示输入，有时候也写个when表示被测函数。

文章插图
对应的，我们的名字的结构搬到我们的代码上，三段式表达，given部分还是输入，when部分就是被测函数，然后then部分写各种assertion来校验。

文章插图
然后就是粒度问题，通常一个测试只测一个case，这样一旦报错了，我们就可以英语立刻知道是哪里的问题，从而减少寻错时间。
迭代4你是一名翻译体育老师，在某次课距离下课还有五分钟时，你决定搞一个游戏。此时有200名学生在上课。游戏的是什么规则是：
让所有学生拍成一队，然后按顺序报数。学生报数时，如果所报数字是3的倍数，那么不能说该数字，而要说Fizz；如果所报数字是5的倍数，那么要说Buzz；如果所报数字是第7的倍数，那么要说Whizz 。学生报数时，如果所报数字同时是两个特殊数的倍数情况下，也要特殊处理，比如3和5的倍数，那么不能说该数字，而是牛津要说FizzBuzz，以此类推。如果同时是三个特殊数的倍数，那么要说FizzBuzzWhizz 。学生报数时，如果所报数字包含了3，那么也不能说该数字，而是要说相应的单词，比如要报13的同学应该说Fizz 。如果数字中包含了3，那么忽略规则2和规则3，比如要报35的同学只报Fizz，不报BuzzWhizz 。如果数字中包含了5，那么忽略规则4和规则5，并且忽略被3整除的判定，比如要报35的同学不报Fizz，报BuzzWhizz 。如果数字中包含了7，那么忽略规则6中忽略被3整除的判定，并且忽略被5整除的判定，比如要报75的同学只报Fizz，其他case自己补齐。