Day25 - 铁人付外挂测试验收（一） - 自动化测试

刚开始接案的时候，常常为了能赶在结案日来临之前把案子结掉，很多功能都是表面上能运作就拿去交差，心里虽然知道可能会有问题，但总是会抱持着赌一把客户不会发现的心态，就这样请他们测试验收，十次里面大概有十次都会被发现有问题，从此之後我就发现我完全没有赌运，乖乖把功能测试到自己有信心时才请客户验收。

大部分时间我都是用手动测试，如果要测金流外挂，就是每次手动操作一次结帐流程，选择该金流後进行结帐，然後看 Log 有没有喷错。但如果在结帐时有很多栏位要输入，或是要测试某些商品组合时，每进行一次结帐测试都会多花 10~30 秒，别小看这些时间，当重复测试很多次累积起来所消耗的时间就会非常惊人。

另外自己常发生改东墙坏西墙的状况，明明在处理的是 A 功能，做完後也测试过没问题了，结果却发现看似毫无关联的 B 功能坏掉了，而且通常都是等到客户回报才会知道，这样不仅让整个程序码很脆弱，还会降低客户的信任感，因此我开始试着导入自动化测试来稳固程序码。

写测试的目的不是让程序自动根除臭虫，而是能够及早发现问题所在及早治疗。

测试的种类

软件测试有许多不同的类型，主要目的都是为了可以在正式上线前提早发现问题，避免正式上线後因为这问题而造成损失，常见的测试有以下几种：

1.单元测试 Unit Test

针对程序里面的最小单元来进行的测试叫做单元测试，最小单元具体的来说可以是一个函式或是类别中的一个方法，测试的目的在於确保每一个函式或方法回传的结果是如我们所预期的，以及测试当例外状况或错误发生时，回传的结果也是在我们预料之内，藉此提早发现风险。

2.整合测试 Integration Test

结合外部资料来进行测试称之为整合测试，有别於单元测试是要测试最小单元，必须要隔离所有会影响测试结果的外部因素，像是从资料库取得的资料、从 API 拿到的回传结果来进行测试，而整合测试就是把这些外部因素拉进来一起测试的方法，确保当这些最小单元组合在一起并引入外部因素後仍然可以正常运作。

3.端对端测试 End-to-end Test

单元测试与整合测试是从工程师的角度来进行，而端对端测试则是模拟真实使用者的行为来进行测试，像是我们自己在做手动测试一样，只是全部都改为用前端程序搭配浏览器来控制使用者的滑鼠点击、页面跳转等行为，如果以 WooCommerce 来说，就是测试使用者把商品加入购物车、输入结帐资料、选择金流点选结帐按钮等流程。

写单元测试的重点

以投入的成本来看，单元测试是 CP 值最高的种类，因为只是测试最小单元所以执行起来的速度很快，又能预先发现潜在的风险，以下为写单元测试的大原则：

单元测试的命名「要」清晰易懂

可以直接从名称中辨识这个测试的目的是什麽，像是我想要测试金流商的加密演算方法是否有正确运作，命名 test_ironpay_generate_sign() 就能很直观看出来其目的。

单元测试「要」测试 True & False

不仅要验证资料正确的部分，也要考虑到当传入不正确的资料时，看被测试对象会如何反应，以及反应结果是否如我们所预期。

单元测试「要」随手进行

不像整合测试或端对端测试因为需要外部环境的支援所以执行起来会很花时间，单元测试可以每写完一个方法就立刻进行测试，不管是使用命令列工具还是编辑器的扩充套件都能很方便的随时进行测试。

单元测试「要」持续维护

理想上当然是希望写一次就可以永远堪用，但随着功能的演变测试也要跟上，不然就失去了写测试的意义。

单元测试里面「不要」测试实作细节

因为实作有可能会随着功能需求的变更而进行修改，这会导致测试类别也必须要跟着修改，测试应该要把目标放在输出结果的验证而非实作细节。

单元测试里面「不要」使用逻辑

如果在测试里面写了 if else 或其他判断语句，会增加测试的变数，测试要维持最单纯的资料输入以及验证输出的状态。

单元测试之间「不要」共用变数

如同上面提到单元测试的目的就是要测试最小单元，所以每个测试都是可以独立测试运作，有时候我们可能为方便重用测试资料，所以会把测试资料当作变数传入测试中，但这样可能会导致测试产生预期外的错误，如果真有这样的需求可以用 DataProvider 来处理。

金流外挂的测试项目

开发 WooCommerce 外挂的好处是内建的函式或方法都已经经过开发人员的测试，使用他们提供的 API 可以减少出错的机会，所以我们需要测试的项目是我们自行设计的逻辑，以铁人付外挂为例，请求类别 Request、接收类别 Response 以及工具类别 Utility 就是应该着重测试的地方。

下一篇我们以测试 Utility 类别里面的三个方法为例，来说明如何在外挂中导入单元测试，以及介绍 VSCode 实用的套件来加速测试流程。

本文同步发表於：https://oberonlai.blog/tw/woocommerce-payment-testing/