高效程序的45个习惯---第五章 敏捷反馈

19 守护天使

 

单元测试。

 

用代码来测试变量的具体值。已经是非常的普遍的做法。你可以选择一个标准的测试框架，来帮忙你完成简单的编写和组织测试的工作，如Java的JUint, C# 或者.Net的NUit等。

 

只要有了单元测试，就要让它们自动运行。也就是每次编译或者构建代码的时候，就运行一次。把单元测试的结果看作是和编译器一样，如果测试没有通过（或者没有测试），那就像编译没有通过一样糟糕。

 

单元测试是最受欢迎者的一种敏捷实践，有很多图书和其他资料可以帮你起步。如果你是新手，建议阅读《单元测试之道》。

 

如果想要自动化地连接单元测试，可以阅读《项目自动化之道》。

 

如果仍然在寻找开始单元测试的理由，下面有很多：

 

1 单元测试能及时提供反馈。你的代码会重复得到锻炼。但若修改或者重写了代码，测试用例就会检查你是否破坏了已有的功能。你可快速得到反馈，并很容易修复它们。

2 单元测试让你的代码更加健壮。测试帮助你全面思考代码的行为，帮你练习正面，反面以及异常情况。

3 单元测试是有用的设计工具。 单元测试有助于实现简单的，注重实效的设计。

4 单元测试是让你自信的后台。你测试代码，了解它在各种条件下的行为。这会让你面对新的任务，时间紧迫的巨大压力下，找到自信。

5 单元测试是解决问题时的探测器。单元测试就像是测试印制电路板的示波镜。

 

平衡的艺术

 

1 单元测试是优质股，值得投资。

 

2单元测试只有达到一定的覆盖范围的时候，才能得到有效作用。

 

3不是测试越多质量就越高，测试必须是有效。

 

 

20 先用它再实现它

 

先写测试，你就会站在代码用户的角度来思考，而不仅仅是一个单纯的实现者。

这样做是有很大区别的，你会发现因为你自己要使用它们。所以能设计一个更有用，更一致的接口。

 

除此之外，先写测试有助于消除过度复杂的设计，让你可以专注于真正需要完成的工作。

 

平衡的艺术

 

1 不要把测试优先和提交代码之前的测试等同起来。测试先行可以帮助你改进设计，但是你还是需要在提交代码之前做测试。

2 任何一个设计都可以被改进。

3 你在验证一个想法或者设计一个原型的时候，单元测试也许并不适合。

4 单纯的单元测试无法保证好的设计。但它们会对高度有帮助。会让设计更加简单。

 

 

 

21不同的环境，就有不同问题

不同环境，就有不同的问题。使用持续集成工具，在每一种支持的平台和环境运行单元测试。要积极地寻找问题，而不是等问题来找你。

 

平衡的艺术

 

1 硬件比开发人员的时间便宜。但如果你有很多配置，要支持大量的平台，可以选择啸声些平台需要内部测试。

 

2 只因为不同的栈层顺序，不同的单词大小写等，就能发现很多平台上的bug.

 

 

 

 

22 自动验收测试

 

平衡的艺术

 

1 不是所有的客户都能给你提供正确的数据。如果他们已经有了正确的数据，就根本不需要新系统了。

 

2 你也许会在旧系统中发现以前根本不知道的bug.或者以前不存在的真正问题。

 

3 使用客户的业务逻辑，但是不要陷入无边无际的文档写作之中。

 

23 度量真实的进度

 

平衡的艺术

 

1 6分钟作业一个时间单位，它的粒度实在太细了，这不是敏捷的做法。

2 一周或者一个月的时间单元，它的粒度太粗了，这也不是敏捷的做法。

 

3 关注功能，而不是日程表。

 

4 如果你在一个项目中花费了很时间来了解你所花费的时弊，而没有足够的时间进行工作，那么你在了解你甩花费的时间上花费的时间就太多了。

 

6 一周工作40个小时，不是说你有40个小时的编码时间。你需要减去会议，电话，电子邮件以及相关活动的时间。

 

 

24 倾听用户的声音

 

平衡的艺术

 

1 没有愚蠢的用户。

2 只有愚蠢，自大的开发人员。

3 “它就是这样的。”这不是一个好的答案。

4 如果代码问题解决不了，也许可以考虑通过修改文档或者培训来弥补。

5 你的用户有可能会阅读所有的文档，记住其中的所有内容。但也可能不会。