在TDD训练营中，经常有小伙伴对测试命名提出疑问：
- 他的测试名好像没有跟Task保持语义一致，不是说Task要翻译Task的吗？
- 咦，测试名字中这些奇奇怪怪的数字代表什么意思呢，为什么是3而不是5？
可能有人心中吐槽：“为什么要讨论这个无聊的问题？怎么命名，只要能表达测试意图就好了呀。” 就是这样一句无心的吐槽道出了命名的核心价值，在讨论怎么命名的之前，还是要讨论一下为什么要命名？
测试即文档， 为了不让这句话成为空口号，值得琢磨琢磨。
测试能够发挥需求文档的价值，就得多想想如何能够让别人看到测试名就快速理解和匹配上业务需求。来看一个测试命名的案例：
@Test
class RegularItemTest{
void should_quality_is_4_and_sellIn_is_3_when_update_given_quality_is_5_and_sellIn_is_4(){
......
}
}
上述测试代码源于镶金玫瑰的业务需求：
“镶金玫瑰”！这是一家魔兽世界里的小商店。出售的商品也都是高质量的。但不妙的是，随着商品逐渐接近保质期，它们的质量也不断下滑。现邀请你开发一个IT系统，从而能够在每过去一天后，对商店中商品的信息做出对应的更新。
首先，简单介绍一下我们的商品特性：
1. 所有商品都有一个SellIn值，这是商品距离过期的天数，最好在这么多天之内卖掉
2. 所有商品都有一个Quality值，代表商品的价值
商品的SellIn值和Quality值，它们每天会发生变化，但是会有特例
商品的价格规则说明如下：
1. 商品每过一天价值会下滑1点 ，一旦过了保质期，价值就以双倍的速度下滑
2. 商品的价值永远不会小于0，也永远不会超过50
3. 陈年干酪（Aged Brie）是一种特殊的商品，放得越久，价值反而越高
4. 萨弗拉斯（Sulfuras）是一种传奇商品，没有保质期的概念，质量也不会下滑
5. 后台门票（Backstage pass）和陈年干酪（Aged Brie）有相似之处：
1. 越接近演出日，商品价值Quality值反而上升
2. 在演出前10天，价值每天上升2点
3. 演出前5天，价值每天上升3点
4. 一旦过了演出日，价值就马上变成0
阅读了业务需求后，你是能够将该测试归类到某种业务Task：
Given 常规商品，未过保，价值在 0 ~ 50之间
When 按天更新
Then 保质期和价值均减少1
不难看出，上述的Test命名是该场景的一个具体的实例化，实例化有实例化的好处，但实例化也会造成了一些理解Gap，为什么这么说？同样的业务Task，来看看另一个小伙伴的Test命名：
@Test
class RegularItemTest{
void should_quality_and_sellIn_decrease_by_1_when_update_given_in_sell_and_quality_between_0_50(){
// 在构造测试数据的时候，quality = 5，sellIn = 4
}
}
前者使用了业务场景实例法，后者使用了业务场景归纳法，后者将前者的实例放到测试代码体重。对比来看，在测试即文档这一点上，业务场景归纳法显然略胜一筹，能够让人读完就能对应到特定的需求场景中。
在使用业务场景归纳法的时候，值得注意的是边界条件，比如在镶金玫瑰中，商品的价值边界0，50，保质期的边界是0，而边界场景是我们要充电考虑的，遇到这种边界条件的时候，推荐你写一个具体的值，比如：
@Test
class RegularItemTest{
void should_quality_be_same_and_sellIn_decrease_by_1_when_update_given_in_sell_and_quality_is_0(){
// 在构造测试数据的时候，quality = 0，sellIn = 4
}
}
对于这个命名，你能很快对应到哪种边界场景吗？
网友评论