当单元测试、集成测试不可被信任时, 我们该做些什么?

这么多年来，我们一直都在被 “制式的教育” 着⋯

• 单元测试是保证质量的必要的手段，无论如何是一定要做的。

但有人能说得清楚，单元测试到底能保证什么样的质量吗？是至多只能保证 “某个开发人员代码的质量”？我们是否真正有深度的思考过：保证 “某个开发人员代码的质量” 与 “保证产品的质量” 间的对应关系？

许多人都会说，Ken 你问这些问题，就代表着你不懂单元测试⋯

是的，我是不懂单元测试；我更不懂的是，为何会有开发人员在“完全不明白” 自己苦苦、甚至是熬夜所写出的单元测试用例与产品质量间的关系时，还是愿意傻傻的在那写单元测试用例？！

这么多年来，我们一直都被 “制式的教育” 着⋯

• 自动化、手工集成测试用例一定要做到如何，如何，产品才能发布。

但，有人能说得清楚，每一次的版本开发中，产品代码 （架构） 上的变化、实际运维环境上的变化与集成测试用例、集成测试环境间的差异吗？

假如，没有人能说得清楚，我们又怎能信任自动化、手工集成测试？！

这么多年来，我们总是被 “制式的教育” 着⋯

• 使得我们每个人都成为执行敏捷工程实践的高手，但，同时，我们却往往没法回答在产品开发上的一些 “Common Sense” 的问题？！

我们是不是应该要抛弃过往的 “制式教育” 中的单元测试与集成测试？！ 而重新的思考 “真正有效”、“真正高效” 的测试方法，测试工具？！

思考着这些测试方法、测试工具其实ㄧ点都不难的；在2014 年，我也只是想着，不要再写笨重、无用的需求文档、设计文档，但又能保证产品的质量与提升开发的效率，所以，就整合了既有的一些工程实践，创建了 Story 场景树。

所以, 我们要思考的是:

• 抛弃 “建树不见林” 的单元测试, 并不代表著我们是在舍弃所谓的 “类(Class) 级别的白盒测试”。而是我们要重新的设计一测试方法、测试框架, 可将 “产品关键的业务场景” 以正确且轻量级的方式, 传递到 “类(Class) 级别的白盒测试”上。
• 抛弃 “自我安慰式” 的集成测试, 并不代表著我们是在舍弃所谓的 “特性/产品间的集成交互测试”。 而是我们要重新的设计一测试方法、测试工具, 可将 “产品运维的环境、场景” 带到 “特性/ 产品间的集成交互测试”。更重要的是, 我们应该是以 ”产品运维的环境、场景” 来设计 “特性/ 产品间的集成交互测试” 的自动化测试用例。

所以, 当单元测试、集成测试不可信任时, 我们应该重新的创建、设计  “真正有效”、“真正高效” 的测试方法，测试工具。而我们要问的问题，应该不是：真正高效的测试方法及工具是什么？而是应该要问：创建高效的测试方法及工具，所需的背后的思维是什么？然后，照着这样的思维，你就能自己去创建、设计出属于你自己所需要的测试工程实践与测试工具。

建议不要只是期望着看到答案，却永远不知道答案是怎么来的；因为，总是只看到答案，学习答案，这样永远也学不完的; 会学得好累、好鬰闷。

自己创建，就相对的要轻松、自主的多了。