[DAY5] 病识感──当我们关注到测试

能载舟，能覆舟

前几篇似乎说了很多 Rails 的坏话，但其实 Rails 是一套工具，工具没有好坏之分，只有是否适合、怎麽使用。Rails 最重要的设计理念是 惯例优先於设定──很多事都帮先帮你做好了，这些惯例不一定适用在所有专案，但在发展初期不会有大影响──这种特色可以在短时间内快速的建立网页应用程序，因此特别适合新创公司，用来迅速验证新兴商业模式、并应对时时变动的需求。

当专案开始成长，渐渐会需要许多客制化的设定和设计，然而一开始使用的惯例会产生一股惯性，这样的惯性会使专案很难再去调整，因此也就会使整个专案渐渐的腐化。

至此对 Rails 的特性的介绍，提供作为了解後续奋斗史的背景参考。接着呈现，在一切奋斗的开端，团队如何意识到「嗯？好像不太对劲？」，以及仔细检视後挖掘出的潜在问题。

病识感

身为开发者，需要评估开发某个需求的时长，在开发完後检讨预估时间和实际开发时间是否相符；其中观察到，实际开发时间都会比预估时间多，表示有某个环节出问题，於是开始寻找流程中花最多时间处理什麽事。

仔细检讨後发现，花了最多时间在测试，检查新功能的运作、以及保证其他原有功能不被影响，而前述「测试」大多是在 local 跑 server 後去操作网页，流程非常没有效率，执行速度很慢、没办法时时刻刻执行，还需要去资料库建立理想中的测试资料。

既然如此，补测试来取代手动测试是不是就能解决问题了呢?
但事实却是，当我们关注到测试的品质与涵盖范围，着手写新测试，却发现比写新功能还难，同时意识到旧有的测试并不有效，原因有以下几点：

• 大部分旧有测试是测页面上的文字
  页面上的文字常会因为行销需求需要不同论述而做调整，也没办法测出底下的业务逻辑是否有正常运行，因此被我们视为无效测试，没有继续维护。

• 每个测试都需要处理大量 association 关系
  假设 DB 中有限制每张订单 Order 都会需要有对应的 Customer

  为了维持资料正确性会在 DB 上加上许多 constraint

  这时候所有有关 Order 的测试，在建立测资时就必须连同 Customer 一起建立，然而并不是所有 Order 的操作都会跟 Customer 有关系。这导致需要花很多时间去处理不相关的测资，除此之外执行测试的时间也会延长许多。

  另一种作法是把 Order 整个 mock 掉，但这种做法有高机率连同新写的逻辑一起 mock 掉

• 写在 view 和 controller 的逻辑难测试
  如果要在这些地方做测试，需要载入整个专案并把 server 跑起来，这样的测试已经不是 unit test ，执行需要花很多时间间接导致开发时间延长。开发时都会用手动检查(在本地端开server 跑看看)取代这样的测试

下一篇终於要开始描述我们如何面对这些问题，并述说我们所做的决定和每一步。

这些走过的路不一定是最短的路，也不一定会是最好的决策，是我们在有限的时间和人力资源下所做的决定，因此後续的篇章会比较偏向分享心得，而不是针对上述问题的解答。