chapter 1~5自问自答

最近公司里跟同事一起组织了个study group学习<xUnit Test Pattern>这本书。线下读书，每周例会讨论。大家提出自己的问题，然后供会上深入讨论。
这里是前五章我的问题和自己的回答。（Page X/Y中X是英文版页码，Y是中文版。）

• Chapter One, Brief Tour
• Page 7/6, How to write the unit test for GUI class?
  • 我觉得首先不应该让GUI类包含太多的逻辑，而应该使用MV*等模式对UI和逻辑进行分离。这样子，即使只对逻辑部分进行测试而不写UI类的测试，也会有很好的效果。
  • 对于UI类，无论是web，android还是iOS，都可以对UI元素进行很好的操作和验证。所以，在逻辑测试的基础上，也可以写以UI为测试接口，以(UI类+逻辑类）为测试对象的更大的测试。但根据分层的原则，逻辑测试应该比UI测试更多更细。如果代码质量不好，M和V没有明确分离，也可以先以这种方式针对UI测试，然后再在重构的过程中把一些很细节的测试下移。
• Page 7/6, How do you manage your testcase class? Any experience of writing several testcase class for one production class?
  • 几乎都是一个工作类，一个测试类。如果工作类太大，我想可以一个工作类对应多个测试类。每个测试类针对工作类的一个feature。但如果一个类太大，是不是该将工作类分为多个小类呢？
• Chapter Two, Test Smells
• Page 13/10, What causes the "behavior sensitivity"?
  • 如果工作代码改了，这时候修改测试代码是一种正常行为。问题在于“sensitivity"。如果工作代码改了，需要修改很多的测试代码，那就是个问题了。我想主要原因是测试代码之间有重复，或者说多个测试方法测试了同一个行为。所以我觉得，Auto Test的用例设计，也应该跟manual test一样，需要尽量以最小的设计用例覆盖尽量多的功能。用例之间应该又更好的正交性。
  • 另外一个原因，例如A依赖于B。我们对A和B都写了单元测试。此时B的行为修改了，同时导致了A的行为发生变化。所以A和B的测试都要修改。一种解决办法是A依赖于B的test double，它适用于B的接口没有变化但B的行为发生变化。但过多的test double也会增加测试的维护成本，例如在B的接口发生变化的情况，就需要重新实现B的替身（即使用mock工具也要修改代码）。
• Page 15/11, Why does the author say only using debugger "in rare cases"?
  • 我想到了软件开发的八荣八耻，所以有这个问题。我想原因就是足够高的test coverage，可以提高足够的定位能力。同时，这需要assetXXX失败的错误信息需要有很好的提示和定位作用。
• Chapter Three, Goals of Test Automation
• Page 21/14, What do you think about figure 3.2? Do you have any experience that automated test causes total cost of software development going up?
  • 之前WebDrvier的经历就属于这种，虽然它并非单元测试。有人在微博里说auto test是一种debt。我非常认同。如果自动测试写的不好，经常要花很多时间来为新功能添加新的测试或者修复失败的测试。
• Page 23/16, What do you think about "Tests should help us understand the SUT"? Do you have some experience in understanding the SUT by testing?
  • 我有时理解不要一段代码，就找出其单元测试代码来看，看看在测试中如何使用，其效果经常比读详细文档更好。这些情况多发生于一些基础类库。这些类库较少依赖于其他类，所以也很少使用test double。test double多了，可读性就降下来了。所以对于一些UI类，integration test（使用真实的model）的可读性会比Unit Test（狭义的Unit Test，model使用test double）好很多。
  • 我觉得单元测试的这个功能被大大低估了。即使只为了理解SUT，而不是为了质量，单元测试也是值得的。
• Page 23/16, Whan's unit test?
  • 有的人认为只有针对单个类的测试才是单元测试。我觉得，如果不跨越进程，都是单元测试，因为测试技术和效果都是类似的。
• Page 24/16, The author says "By definition, legacy code doesn't have a suite of automated regression tests". What's your definition for "legacy code"?
  • 想到这个问题还是因为<修改遗留代码的艺术>那本书。我很赞同其中对遗留代码的定义，就是没有单元测试的。因为没有单元测试，所以不敢随便的修改功能，哪怕只是删除eclipse提示没被调用的代码，说不定被reflection调用呢？
• Page 28/19, What are the cons and pros of creating "Test Utility Methods"?
  • 书里有答案，好处是消除代码重复，坏处是因为增加了一层，可能影响可读性。但我觉得还是利大于弊吧，而且是唯一选择。
• Page 28/10, What does "Separation of Concerns" mean for unit test?
  • 关注点分离，应该是说针对不同关注点的功能，应该分离开，或者说放在多个类里，我觉得这是SRP(单一职责原则）的另一种表示。
  • 对测试而言，我觉得每个测试方法应该只测试一件事情。这里“一件事情”是说一个功能点的一条功能路径。于是，每个功能点应该对于一个测试类。
• Page 29/20, Unit test helps or hinders refactor? How to achieve "Robust Test"?
  • 很自然的想法，单元测试应该是帮助重构的，因为没有单元测试没法安全的重构。
  • 但是，在重构的时候，我们要同时修改单元测试代码。所以
• Chapter Four, Philosophy of Test Automation
• Page 32/22, What do you think of TDD? Any experience?
  • 我觉得TDD测试驱动开发的思路很好，但我尝试过，确实很不习惯。Unit Test现在大家都很容易接收，而且都在或多或少，或好或坏的写。但是TDD，仍然是很有争议的。
• Page 34/23, How do you do outside-in development when the dependency class/package is not ready?
  • 使用test double来替代真实的DOC。即使不是为了测试，也可以保证上层模块和下层模块的开发人员可以并行开发，增加开发效率。
Page 36/24, For outside-in develop mode, author says "Once the subordinate classes have been built, we could remove the test doubles from many of the tests"? What's its pros and cons?
• 我觉得作者倾向于谨慎的使用test double。我之前问过一个公司内很资深的测试人员，她也认为real>fake>stub>mock。我也更加倾向于使用真实的DOC，如果它不影响稳定性，速度。这样子的测试可读性更好，减少了构造test double的过程，兼具了对上层和下层模块之间的继承性测试（这个未必是优点）。但同时，针对上层代码的测试可能会因为下层模块的改变而失败。设计上层代码的测试时，应该尽量保证它不被下层模块的改变而破坏。这个以后实践中多多体会。
• Page 36/24, What's the difference between "State Verification" and "Behavior Verification"?
  • 问这个只是为了统一下看法。前者是验证SUT的状态，后者是验证SUT进行的操作。现在大多数人都倾向于前者。后者必须要使用test double（spy或者mock），而且从理念上来说，它面向实现而非策略，所以更不稳定。
• Chapter Five, Principles of Teset Automation
• Page 40/28, What's "Testability"?
  • 整天大家都在说可测试性，内涵倒问题不大，就是测试对象容易被测试，但外延呢？而且针对不同测试又有何种表现呢？
  • 对单元测试而且，我觉得通过seam注入test double的能力是很重要的可测试性。
• Page 40/28, What's the "Front Door" and "Back Door" in unit test?
  • 前门表示测试代码通过调用SUT的函数而操作SUT或者或者SUT的状态。
  • 后门则是通过各种test double，操作或者检测SUT和DOC之间的交互。
• Page 41/28, Do you have "Conditional Test Logic" in your test method?
  • 理论上是不应该有的。因为一个测试只有一个路径，if-else只能走一个，所以为了要写条件分支呢？
• Page 44/30, What's the pros for "Minimize Test Overlap"? Is it possible to have no test overlap?
• Page 44/30, How to test multithread code?
  • 多线程测试比UI测试更麻烦。我想主要有两条路可走：异步变同步和等待异步结束。
  • 异步变同步是把异步的调用变为同步调用，这需要SUT中留下seam进行改变。需要设计时考虑这种测试需求。
  • 等待异步结束最简单的办法就是sleep。进一步是sleep-wait-loop。还有一种扩展是线程结束时，主动告诉测试线程操作结束。
• Page 45/31, When one test's start state is end state of another one, you will write them in one test or split them to two?
  • 虽然现实中我写过不少这种测试，但确实是很坏的smell，违法了一个测试只该测试一种条件的原则。
Page 46/31, Do you have more than one exercise SUT phase or more than one result verification phase in one the method?
• 上面问题的另外一个角度的提问。我觉得都是坏味道。