Apply suggestions from code review

Co-Authored-By: ArvinH <[email protected]>

Author: lenchen1112

Diff for: 1-js/03-code-quality/05-testing-mocha/3-pow-test-wrong/solution.md

@@ -2,11 +2,11 @@
 
 這邊我們實際上有三個測試，但卻只用單一個函式來寫三句斷言。
 
-有時候這種方式更容易寫，但若問題產生時，想知道是什麼出問題也更不明顯了。
+有時候這種方式更容易寫，但若問題產生時，想知道是什麼出問題也就更不明顯了。
 
 若錯誤發生在複雜執行流程的中間，那我們得知道那個時間點的資料是什麼。我們實際上就必須 *除錯該測試*。
 
-打散該測試為多個清楚寫下輸出輸入的 `it` 區塊會更好。
+將測試打散為多個清楚寫下輸出輸入的 `it` 區塊會更好。
 
 像這樣：
 

Diff for: 1-js/03-code-quality/05-testing-mocha/article.md

@@ -8,7 +8,7 @@
 
 在開發中，我們可以經由執行它得到的結果來跟預期做比較，並檢查該函式。例如，我們可以在主控台中這樣做。
 
-若有東西不對勁 -- 那我們會修復程式碼、再次執行並檢查結果 -- 等等事情直到它運作正常。
+若有東西不對勁 -- 那我們會修復程式碼、再次執行並檢查結果 -- 持續這流程直到它運作正常。
 
 但這種手動 "重新執行" 並不完美。
 
@@ -110,7 +110,7 @@ describe("pow", function() {
 
 目前，測試是失敗的，有個錯誤存在。這符合邏輯：我們只有一個空函式 `pow`，所以 `pow(2, 3)` 回傳 `undefined` 而非 `8`。
 
-未來，留意還有更多高層次的測試工具，像是 [karma](https://karma-runner.github.io/) 和其它，可以簡單地自動執行多種測試。
+為了將來，讓我們留意一下還有更多高層次的測試工具，像是 [karma](https://karma-runner.github.io/) 和其它，可以簡單地自動執行多種測試。
 
 ## 初始實作
 
@@ -383,14 +383,14 @@ function pow(x, n) {
 2. 作為 **文件** -- `describe` 和 `it` 的標題說明了函式在做什麼。
 3. 作為 **範例** -- 測試實際上運行範例來顯示函式如何被使用。
 
-有著規格，我們可以安全的改進、更動、甚至重頭寫函式，且保證其依然運作正確。
+有了規格，我們可以安全的改進、更動、甚至重頭寫函式，且保證其依然運作正確。
 
 當函式被用在大型專案中的多處時更是特別重要。當我們改變一個函式，是沒辦法只用手動檢查是否各個使用它的地方都運作順利的。
 
 沒有測試時，會有兩種作法：
 
 1. 無論如何就是更改。然後我們的使用者遇到錯誤，因為我們也許在手動測試某些東西時失敗了。
-2. 或者，若錯誤的懲罰很嚴重時，因為沒有測試，人們會變得畏懼修改這些函式，進而程式碼變得過時且沒人想動它，這對開發來說很不好。
+2. 或者，若發生錯誤的代價很高時，因為沒有測試，人們會變得畏懼修改這些函式，進而程式碼變得過時且沒人想動它，這對開發來說很不好。
 
 **自動化測試有助於避免這些問題！**