Merge pull request #141 from YukiOta/ja-trans/4.5

4.5 Avoid global test fixtures and seeds, add data per-test の翻訳

README.japanese.md

@@ -473,13 +473,13 @@ All statements above will return false if used with `===`
 
 <br/><br/>
 
-## ![✔] 4.5 Avoid global test fixtures and seeds, add data per-test
+## ![✔] 4.5 グローバルなテストフィクスチャとシードを避け、テストごとにデータを追加する
 
-**TL;DR:** To prevent tests coupling and easily reason about the test flow, each test should add and act on its own set of DB rows. Whenever a test needs to pull or assume the existence of some DB data - it must explicitly add that data and avoid mutating any other records
+**TL;DR:** テスト同士が結合してしまうことを防ぎ、テストフローの理解を容易にするために、各テストは独自の DB データ行のセットを用意し、それらを利用して実行されるべきです。テストがいくつかの DB データをプルしたり、その存在を仮定する必要がある場合には、明示的にデータを追加し、他のレコードに変更を加えないようにしなければなりません。
 
-**Otherwise:** Consider a scenario where deployment is aborted due to failing tests, team is now going to spend precious investigation time that ends in a sad conclusion: the system works well, the tests however interfere with each other and break the build
+**さもないと:** テストが失敗したことによってデプロイが中止されるというシナリオを考えてみましょう。チームは貴重な時間を調査に費やし、結果として悲しい結論にたどり着きます: システムは機能していますが、テスト同士が干渉しあって、ビルドを壊しているのです。
 
-🔗 [**Read More: Avoid global test fixtures**](/sections/testingandquality/avoid-global-test-fixture.md)
+🔗 [**さらに読む: グローバルなテストフィクスチャとシードを避け、テストごとにデータを追加する**](/sections/testingandquality/avoid-global-test-fixture.japanese.md)
 
 <br/><br/>
 

sections/testingandquality/avoid-global-test-fixture.japanese.md

@@ -1,17 +1,17 @@
-# Avoid global test fixtures and seeds, add data per-test
+# グローバルなテストフィクスチャとシードを避け、テストごとにデータを追加する
 
 <br/><br/>
 
-### One Paragraph Explainer
+### 一段落説明
 
- Going by the golden testing rule - keep test cases dead-simple, each test should add and act on its own set of DB rows to prevent coupling and easily reason about the test flow. In reality, this is often violated by testers who seed the DB with data before running the tests (also known as ‘test fixture’) for the sake of performance improvement. While performance is indeed a valid concern — it can be mitigated (e.g. In-memory DB, see “Component testing” bullet), however, test complexity is a much painful sorrow that should govern other considerations. Practically, make each test case explicitly add the DB records it needs and act only on those records. If performance becomes a critical concern — a balanced compromise might come in the form of seeding the only suite of tests that are not mutating data (e.g. queries)
+テストケースをこれ以上ないほどシンプルに保つ、という黄金のテストルールに則り、各テストは、テスト同士が結合するのを防ぎ、テストフローの理解を容易にするために、各自のデータセットを用意して実行されるべきです。実際には、これはしばしば、パフォーマンス向上を目的としてテストを実行する前に DB にシードデータを与える（「テストフィクスチャ」としても知られています）テスターによって違反されています。もちろんパフォーマンスは懸念するべき事項ではありますが、それは緩和することができます（例えば、インメモリ DB、「最低でも、API（コンポーネント）のテストを書く」の項目を参照してください）。しかしながらテストの複雑さは、他の懸念事項を凌駕するほどの、はるかに痛みを伴う悲痛の種です。現実的には、各テストケースに必要な DB レコードを明示的に追加させ、それらのレコード上でのみ実行させるべきです。もしパフォーマンスがクリティカルな懸念事項になる場合には、バランスを考慮した妥協案として、データに変更を加えない唯一のテストスイート（例えば、クエリ）をシードする、という形がありえます。
 
 <br/><br/>
 
-### Code example: each test acts on its own set of data
+### コード例: 各テストが独自のデータセットを用いて実行される
 ```javascript
 it('When updating site name, get successful confirmation', async () => {
-  //test is adding a fresh new records and acting on the records only
+  // テストは新しいデータを追加し、そのレコードのみを利用して動作しています
   const siteUnderTest = await SiteService.addSite({
     name: 'siteForUpdateTest'
   });
@@ -22,21 +22,21 @@ it('When updating site name, get successful confirmation', async () => {
 
 <br/><br/>
 
-### Code Example – Anti Pattern:  tests are not independent and assume the existence of some pre-configured data
+### コード例 – アンチパターン:  テストが独立しておらず、事前に整えられたデータの存在を仮定している
 ```javascript
 before(() => {
-  //adding sites and admins data to our DB. Where is the data? outside. At some external json or migration framework
+  // サイトと管理者のデータを DB に追加しています。データはどこにあるのでしょうか？外部ファイルです。外部の json ファイルか、もしくは マイグレーションフレームワークです。
   await DB.AddSeedDataFromJson('seed.json');
 });
 it('When updating site name, get successful confirmation', async () => {
-  //I know that site name 'portal' exists - I saw it in the seed files
+  // 私は「Portal」という名前のサイトがあることを知っています - シードファイル上で確認したのです
   const siteToUpdate = await SiteService.getSiteByName('Portal');
   const updateNameResult = await SiteService.changeName(siteToUpdate, 'newName');
   expect(updateNameResult).to.be(true);
 });
 it('When querying by site name, get the right site', async () => {
-  //I know that site name 'portal' exists - I saw it in the seed files
+  // 私は「Portal」という名前のサイトがあることを知っています - シードファイル上で確認したのです
   const siteToCheck = await SiteService.getSiteByName('Portal');
-  expect(siteToCheck.name).to.be.equal('Portal'); //Failure! The previous test change the name :[
+  expect(siteToCheck.name).to.be.equal('Portal'); // 失敗しました！前のテストがサイト名を変更しています :[
 });
 ```