Post by "WantSong", 03-23-2007, 12:29
-----------------------------------------------------
由于几乎所有的敏捷原则都依赖测试，自动化测试是敏捷的前提和基础。因此我把这篇文章放到测试的坛子。
载自http://www.javaeye.com/topic/64704，作者firebody
* 理解用户真正想要什么了吗？真正的需求已经清楚了吗？
答：不清楚？ 那么请回到需求分析人员那里问清楚。
* 这个接口合理吗？ 如何验证其合理性？
答：先用TDD从最外层的需求构思这个接口（方法名，参数，返回结果）
* 为什么测试如此难写？
答：从功能需求驱动测试代码的编写，何来如此难？ 如果果真如此，那是否可以细分需求呢？
* 一个需求的功能如此复杂，如何让测试尽快通过？
答：小踏步前进。 不要太大胃口。
* 随着测试的增多，代码的完善， 感觉代码有点bad smell,该如何？
答：任何时候你都可以放心立即重构，只要你从前面一步步用测试驱动走来。重构的影响总是在“测试“的自动监控下。
* 奇怪，XP不是宣称尽量使用接口 然后mock吗？ 怎么随着mock行为的增多而导致测试代码越来越复杂了呢？
答 : 请尽量不要使用mock,除非你认为非常有必要。 可以用一段代码一个类来做的事情，何必需要一个mock ?
* 何时需要 mock ?
答: 很难回答这个问题，具体问题具体分析。但是记住mock的几点主要用途：
# mock是用来隔离你写测试的时候不能“关注“的功能部分,比如别人待实现的子模块，网络连接部分，第三方库的接口。
# 如果该mock是待实现的功能模块，则测试的MOCK的目的还在于“推导出“对该功能的“接口推导“作用。
# 关于MOCK的行为，多发一些牢骚吧：
{ 如果Mock的功能依赖于团队中别人待实现的功能A，请尽量减少你的代码的逻辑对该功能A地依赖程度
@ 你期望 功能A来改变你的数据状态，并且你后续的逻辑依赖于这个状态的改变。 那么这样的依赖
是“被警惕“的依赖，或许，这个功能A地实现应该划分到你来实现，而不是让别人来做。因为
你的代码就是在做功能A的部分。 为什么存在这样的结果呢？ 源头或许就是 当初功能分的太细了？
或许，详细设计还是 来得少一些为妙。
@ 你的代码仅仅调用功能A的接口来做一次期望的动作，后面的逻辑并不依赖于功能A所作的动作。（除非异常）
这样的依赖是可以被接受的，也说明功能力度粒度的划分是合理的。
}
* 如何验证测试成功？ 也就是算是完成了用户的需求？
答：尝试从用户的角度来考虑 “通过“的概念。
如果表示成功的验证太过复杂，那么就请思考一种更好得更简洁的验证方式。
* 为了让测试通过，需要分出一些proteced/private的方法来实现功能，这些新增的方法我还需要单独测试吗？
答：不需要，如果需要那么测试力度太低，测试代码严重依赖于功能实现的内部逻辑。而这些内部逻辑不应该反映在以测试驱动的测试代码中
，这种严重的依赖也导致 重构很难进行，因为重构就意味着调整程序的内部结构，程序的内部结构调整，意味着
依赖这些内部功能实现的测试代码也需要调整。这样的工作量不是重构可以接受的，这个结果说明
“为测试而测试“的严重后果。
* 那如何保证我新增的代码得到测试覆盖呢？
答：冒烟了。
* 测试如何才算足够呢？
答：代码里面的每一个边界情况，每一个可以设想到边界输入。 可以考虑到的逻辑没处理到的边界输入情况，任何一个bug都有
对应的测试覆盖到。
* 如何让测试深入每一个开发人员心里呢？
答：告诉他，不会写测试的说明还没真正迈入 高效率开发的大门。或者打击他说：不会写测试的就不算是入门(有危言耸听的嫌疑）。
* 如何在项目里面保证测试的进行随着项目的进行演进？
答：必须明确一个原则：每一个需求点都有单独的测试覆盖到。
* 如何让测试的编写成为强制的制度？
答：每个开发人员需要认识测试的重要性。用自动化的集成工具 保证这种制度能够成为一种“强制“。邮件通知，每日失败通告...。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图