Skip to content

Commit

Permalink
Merge pull request #173 from jcplist/zh_tw
Browse files Browse the repository at this point in the history
Fix typo for ch11-03
  • Loading branch information
weihanglo authored Jul 10, 2023
2 parents 57f400f + 5080438 commit 4f266b7
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions src/ch11-03-test-organization.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@

### 整合測試

在 Rust 中,整合測試對你的函式庫來說是完全外部的程式。它們使用你的函式庫的方式與其他程式碼一樣,所以它們只能呼叫屬於函式庫中公開 API 的函式。它們的目的是要測試你的函式庫屬個部分一起運作時有沒有正確無誤。單獨運作無誤的程式碼單元可能會在整合時出現問題,所以整合測試的程式碼的涵蓋率也很重要。要建立整合測試,你需要先有個 *tests* 目錄。
在 Rust 中,整合測試對你的函式庫來說是完全外部的程式。它們使用你的函式庫的方式與其他程式碼一樣,所以它們只能呼叫屬於函式庫中公開 API 的函式。它們的目的是要測試你的函式庫數個部分一起運作時有沒有正確無誤。單獨運作無誤的程式碼單元可能會在整合時出現問題,所以整合測試的程式碼的涵蓋率也很重要。要建立整合測試,你需要先有個 *tests* 目錄。

#### *tests* 目錄

Expand Down Expand Up @@ -80,7 +80,7 @@ adder

整合測試段落從 `Running tests/integration_test.rs` 開始,接著每行會是每個整合測試的測試函式,最後在 `Doc-tests adder` 段落開始前的那一行則是整合測試的總結結果。

每個整合測試檔案會有自己的段落,如果如果我們在 *tests* 目錄加入更多檔案的話,就會出現更多整合測試段落。
每個整合測試檔案會有自己的段落,如果我們在 *tests* 目錄加入更多檔案的話,就會出現更多整合測試段落。

我們一樣能用測試函式的名稱來作為 `cargo test` 的引數,來執行特定整合測試。要執行特定整合測試檔案內的所有測試,可以用 `--test` 作為 `cargo test` 的引數並加上檔案名稱:

Expand All @@ -92,7 +92,7 @@ adder

#### 整合測試的子模組

隨著你加入的整合測試越多,你可能會想要在 *tests* 目錄下產生更多檔案來協助組織它們。舉例來說,你以用測試函式測試的功能來組織它們。如同稍早提到的,*tests* 目錄下的每個檔案都會編譯成自己獨立的 crate,這有助於建立不同的作用域,這就像是使用者使用你的 crate 的可能環境。然而這也代表 *tests* 目錄的檔案不會和 *src* 的檔案行為一樣,也就是你在第七章學到如何拆開程式碼成模組與檔案的部分。
隨著你加入的整合測試越多,你可能會想要在 *tests* 目錄下產生更多檔案來協助組織它們。舉例來說,你可以用測試函式測試的功能來組織它們。如同稍早提到的,*tests* 目錄下的每個檔案都會編譯成自己獨立的 crate,這有助於建立不同的作用域,這就像是使用者使用你的 crate 的可能環境。然而這也代表 *tests* 目錄的檔案不會和 *src* 的檔案行為一樣,也就是你在第七章學到如何拆開程式碼成模組與檔案的部分。

當你希望擁有一些能協助數個整合測試檔案的輔助函式,並遵循第七章的[「將模組拆成不同檔案」][separating-modules-into-files]<!-- ignore -->段落來提取它們到一個通用模組時,你就會發現 *tests* 目錄下的檔案行為是不同的。舉例來說,我們建立了 *tests/common.rs* 並寫了一個函式 `setup`,然後我們希望 `setup` 能被不同測試檔案的數個測試函式呼叫:

Expand Down Expand Up @@ -133,11 +133,11 @@ adder
{{#rustdoc_include ../listings/ch11-writing-automated-tests/no-listing-13-fix-shared-test-code-problem/tests/integration_test.rs}}
```

注意到 `mod common;` 的宣告與我們在範例 7-21 說明的模組宣告方式一樣。然而後在測試函式中,我們就可以呼叫函式 `common::setup()`
注意到 `mod common;` 的宣告與我們在範例 7-21 說明的模組宣告方式一樣。之後在測試函式中,我們就可以呼叫函式 `common::setup()`

#### 執行檔 Crate 的整合測試

如果我們的專案是只包含 *src/main.rs* 檔案的執行檔 crate 而沒有 *src/lib.rs* 檔案的話,我們無法在 *tests* 目錄下建立整合測試,也無法將 *src/main.rs* 檔案中定義的函式透過 `use` 陳述式引入作用域。只有函式庫 crate 能公開函式給其他 crate 使用,執行檔 crate 只用於獨自執行。
如果我們的專案只包含 *src/main.rs* 檔案的執行檔 crate 而沒有 *src/lib.rs* 檔案的話,我們無法在 *tests* 目錄下建立整合測試,也無法將 *src/main.rs* 檔案中定義的函式透過 `use` 陳述式引入作用域。只有函式庫 crate 能公開函式給其他 crate 使用,執行檔 crate 只用於獨自執行。

這也是為何 Rust 專案為執行檔提供直白的 *src/main.rs* 檔案並允許呼叫 *src/lib.rs* 檔案中的邏輯程式碼。使用這樣子的架構的話,整合測試**可以**透過 `use` 來測試函式庫 crate,並讓重點功能可以公開使用。如果重點功能可以運作的話,那 *src/main.rs* 檔案中剩下的程式碼部分也能夠如期執行,而這一小部分就不必特定做測試。

Expand Down

0 comments on commit 4f266b7

Please sign in to comment.