Merge pull request #148 from YukiOta/ja-trans/4.13

4.13 Test your middlewares in isolation の翻訳

README.japanese.md

@@ -541,17 +541,17 @@ null == undefined; // true
 
 🔗 [**さらに読む: CI プラットフォームを選択する**](/sections/testingandquality/citools.japanese.md)
 
-## ![✔] 4.13 Test your middlewares in isolation
+## ![✔] 4.13 ミドルウェアを分離してテストする
 
-**TL;DR:** When a middleware holds some immense logic that spans many request, it worth testing it in isolation without waking up the entire web framework. This can be easily achieved by stubbing and spying on the {req, res, next} objects
+**TL;DR:** ミドルウェアが多くのリクエストにまたがる巨大なロジックを保持している場合は、ウェブフレームワーク全体を起動することなく、分離してテストする価値があります。これは、{req, res, next} オブジェクトをスタブ化してスパイすることで容易に達成することができます。
 
-**Otherwise:** A bug in Express middleware === a bug in all or most requests
+**さもないと:** Express ミドルウェアにおけるバグ === ほぼ全てのリクエストにおけるバグ
 
-🔗 [**Read More: Test middlewares in isolation**](/sections/testingandquality/test-middlewares.md)
+🔗 [**さらに読む: ミドルウェアを分離してテストする**](/sections/testingandquality/test-middlewares.japanese.md)
 
 <br/><br/><br/>
 
-<p align="right"><a href="#table-of-contents">⬆ Return to top</a></p>
+<p align="right"><a href="#table-of-contents">⬆ トップに戻る</a></p>
 
 # `5. 本番環境移行のプラクティス`
 

sections/testingandquality/test-middlewares.japanese.md

@@ -1,20 +1,20 @@
-# Test your middlewares in isolation
+# ミドルウェアを分離してテストする
 
 <br/><br/>
 
-### One Paragraph Explainer
+### 一段落説明
 
-Many avoid Middleware testing because they represent a small portion of the system and require a live Express server. Both reasons are wrong — Middlewares are small but affect all or most of the requests and can be tested easily as pure functions that get `{req,res}` JS objects. To test a middleware function one should just invoke it and spy ([using Sinon for example](https://www.npmjs.com/package/sinon)) on the interaction with the {req,res} objects to ensure the function performed the right action. The library [node-mock-http](https://www.npmjs.com/package/node-mocks-http) takes it even further and factors the {req,res} objects along with spying on their behavior. For example, it can assert whether the http status that was set on the res object matches the expectation (See example below)
+ミドルウェアはシステムのごく一部であり、Express を起動させる必要があるため、多くの人はミドルウェアのテストを避けます。しかし、どちらの理由も間違っています ー ミドルウェアは小さいですが、すべて、あるいはほとんどのリクエストに影響を及ぼすものであり、`{req, res}` という JS オブジェクトを取得する純粋な関数として簡単にテストできます。ミドルウェア関数をテストするためには、その関数を呼び出して、関数が正しく動作していることを確認するために、{req, res} オブジェクトとのやり取りを（[例えば Sinon を使用して](https://www.npmjs.com/package/sinon)）スパイするべきです。[node-mock-http](https://www.npmjs.com/package/node-mocks-http) というライブラリは、これをさらに発展させ、{req, res} オブジェクトの動作をスパイしながら、そのオブジェクトに要素付けします。例えば、res オブジェクトに設定された http ステータスが期待値と一致しているかどうかを判定することができます（下記の例を参照してください）。
 
 <br/><br/>
 
-### Code example: Testing middleware in isolation
+### コード例: ミドルウェアを分離してテストする
 
 ```javascript
-//the middleware we want to test
+// テストしたいミドルウェア
 const unitUnderTest = require("./middleware");
 const httpMocks = require("node-mocks-http");
-//Jest syntax, equivalent to describe() & it() in Mocha
+// Jest シンタックス、Mocha における describe() と it() と同様
 test("A request without authentication header, should return http status 403", () => {
   const request = httpMocks.createRequest({
     method: "GET",