寫測試是幫我們發現應用中 bug 的好習慣，養成這個好習慣、保持自己的代碼自己測的好心態、找到一個支持你寫測試的好公司…就算走進了成熟的工程師的行列。
但是有時候我們也會想，我用的測試框架已經是一個成熟的測試框架了，它能不能自己寫測試呢？
fast-check
來看看 fast-check 這個庫吧，我們真該呼籲其他的測試庫都來向它學習一下，它會自己主動幫你測 bug，幫你考慮到各種你自己忙裡偷閒寫測試時可能會忘記考慮的邊角情況，讓你少一些 debug 加班的夜晚，早點回家陪老婆！
它可以發現什麼樣的 bug 呢？
比如 js-yaml 庫用了這個 fast-check 之後，查出了這個毛病：
<code>yaml.dump({toto: -10}, {styles:{'!!int':'binary'}})// 本應該輸出 toto: -0b1010// 但是卻輸出 toto: 0b-1010/<code>jest 庫作為一個成熟好用的測試庫，也被 fast-check 檢查到有丟三落四偷雞摸狗的壞習慣：
<code>expect(0).toStrictEqual(5e-324)// 本應該報錯// 但是卻偷偷瞞下不報/<code>
為什麼 fast-check 這麼有意思？因為一般情況下我們寫測試會傾向於寫 happy path 的代碼，也就是隻測了正常流程，沒有用心去考慮各種異常流程。
但 fast-check 使用了「基於屬性的測試 Property-Based Testing」，或者叫「生成式測試 Generative Testing」，會幫你自動生成各種惡劣的情況，嘗試找到最小的反例導致程序出 bug，然後上報給你。簡單來說就是類似於嘗試各種輸入的排列組合，碰撞出有問題的輸入情況。
例如下面的測試就會生成一系列的字符串，嘗試隨機碰撞出 bug：
<code>const 包含 = (text, pattern) => text.indexOf(pattern) >= 0;/<code>
下次寫測試的時候，希望測試能自己寫它自己的話，就可以考慮用 fast-check 來完成工作啦！
分享到:
閱讀更多 張聖聽 的文章
