mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-27 19:17:13 +08:00
translate 4.3
This commit is contained in:
Yuki Ota
@ -455,13 +455,13 @@ All statements above will return false if used with `===`
|
||||
|
||||
<br/><br/>
|
||||
|
||||
## ![✔] 4.3 Structure tests by the AAA pattern
|
||||
## ![✔] 4.3 AAA パターンを用いてテストを構成する
|
||||
|
||||
**TL;DR:** Structure your tests with 3 well-separated sections: Arrange, Act & Assert (AAA). The first part includes the test setup, then the execution of the unit under test and finally the assertion phase. Following this structure guarantees that the reader spends no brain CPU on understanding the test plan
|
||||
**TL;DR:** 上手に分けられた 3 つのセクションを利用してテストを構成してください: Arrange、Act、そして Assert (AAA) です。まず最初の部分でテストのセットアップを行い、次にテスト対象のユニットの実行、そして最後にアサーションフェーズに入ります。この構造に従うことで、コードを読む人がテストプランを理解するために頭脳の CPU を費やさないことが保証されます。
|
||||
|
||||
**Otherwise:** Not only you spend long daily hours on understanding the main code, now also what should have been the simple part of the day (testing) stretches your brain
|
||||
**さもないと:** メインコードを理解するのに長時間費やすだけでなく、今までシンプルな部分であったはずのもの（テスト）が、脳のリソースを奪います。
|
||||
|
||||
🔗 [**Read More: Structure tests by the AAA pattern**](/sections/testingandquality/aaa.md)
|
||||
🔗 [**さらに読む: AAA パターンを用いてテストを構成する**](/sections/testingandquality/aaa.japanese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
|
||||
@ -1,20 +1,20 @@
|
||||
# Structure tests by the AAA pattern
|
||||
# AAA パターンを用いてテストを構成する
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### One Paragraph Explainer
|
||||
Our biggest testing challenge is the lack of headspace - we already have the production code keeping us super-busy. For this reason the testing code must stay dead-simple and easy to understand. When reading a test case - it shouldn't feel like reading imperative code (loops, inheritance) rather more like HTML - a declarative experience. To achieve this, keep the AAA convention so the readers' mind will parse the test intent effortlessly. There are some other similar formats to this pattern, like XUnit 'Setup, Excercise, Verify, Teardown'. These are the three A:
|
||||
### 一段落説明
|
||||
|
||||
The 1st A - Arrange: All the setup code to bring the system to the scenario the test aims to simulate. This might include instantiating the unit under test constructor, adding DB records, mocking/stubbing on objects and any other preparation code
|
||||
テストにおける最大の課題は、私たちの頭の容量不足です ー 既存のプロダクションコードで、私たちはすでに手一杯なのです。そのため、テストコードは非常にシンプルで、理解しやすいものでなければなりません。テストケースを読んでいるときは、命令的なコード（ループ、継承）を読むような感じではなく、むしろ HTML のように、宣言的なコードを読むような感覚を持つべきです。これを実現するには、コードを読む人がテストの意図を楽に汲み取れるように、AAA という慣習を守ってください。このパターンに似た形式として、XUnit の 'Setup, Excercise, Verify, Teardown' のようなものがあります。3 つの A は次の通りです:
|
||||
|
||||
The 2nd A - Act: Execute the unit under test. Usually 1 line of code
|
||||
1 つ目のA - Arrange（アレンジ）: テストがシミュレートするシナリオにシステムの環境を設定するための、すべてのセットアップコードです。これには、テストコンストラクタ対象ユニットのインスタンス化、DB レコードの追加、オブジェクトのモック／スタブ、その他準備のためのコードが含まれるかもしれません。
|
||||
|
||||
The 3rd A - Assert: Ensure that the received value satisfies the expectation. Usually 1 line of code
|
||||
2 つ目のA - Act（アクト）: テスト対象のユニットを実行します。通常、1 行のコードです。
|
||||
|
||||
3 つ目のA - Assert（アサート）: 得た値が期待する条件を満たすことを確認します。通常、1 行のコードです。
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code example: a test strcutured with the AAA pattern
|
||||
### コード例: AAA パターンで構成されたテスト
|
||||
```javascript
|
||||
describe.skip('Customer classifier', () => {
|
||||
test('When customer spent more than 500$, should be classified as premium', () => {
|
||||
@ -34,7 +34,7 @@ describe.skip('Customer classifier', () => {
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### Code Example – Anti Pattern: no separation, one bulk, harder to interpret
|
||||
### コード例 – アンチパターン: 分割無し、一塊の、解釈の難しいコード
|
||||
```javascript
|
||||
test('Should be classified as premium', () => {
|
||||
const customerToClassify = {spent:505, joined: new Date(), id:1}
|
||||
@ -47,15 +47,15 @@ test('Should be classified as premium', () => {
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### "Include 6 parts in each test"
|
||||
### "Include 6 parts in each test"（各テストに 6 つの要素を含めましょう）
|
||||
|
||||
[From the blog "30 Node.js testing best practices" by Yoni Goldberg](https://medium.com/@me_37286/yoni-goldberg-javascript-nodejs-testing-best-practices-2b98924c9347)
|
||||
[Yoni Goldberg によるブログ "30 Node.js testing best practices"](https://medium.com/@me_37286/yoni-goldberg-javascript-nodejs-testing-best-practices-2b98924c9347)
|
||||
|
||||
|
||||
|
||||
|
||||
<br/><br/>
|
||||
|
||||
### "It is important for the test reader to be able to quickly determine what behavior the test is verifying"
|
||||
From the book [XUnit Patterns](http://xunitpatterns.com/Four%20Phase%20Test.html):
|
||||
### "It is important for the test reader to be able to quickly determine what behavior the test is verifying"（テストコード読者にとって重要なことは、テストがどんな挙動を検証しているのかすぐに判断できることです）
|
||||
書籍 [XUnit Patterns](http://xunitpatterns.com/Four%20Phase%20Test.html) より:
|
||||
|
||||
> It is important for the test reader to be able to quickly determine what behavior the test is verifying. It can be very confusing when various behaviors of the system under test (SUT) are being invoked, some to set up the pre-test state (fixture) of the SUT, others to exercise the SUT and yet others to verify the post-test state of the SUT. Clearly identifying the four phases makes the intent of the test much easier to see.
|
||||
> テストコード読者にとって重要なことは、テストがどんな挙動を検証しているのかすぐに判断できることです。様々なテスト対象システム（the system under unit, SUT）の挙動が呼び出されると、非常に複雑になります。あるものは SUT のプレテスト状態（フィクスチャー）をセットアップし、またあるものは SUT を動かし、さらには SUT のポストテスト状態を検証したりする状況です。4 つのフェーズを明確に識別することで、テストの意図がよりわかりやすくなります。
|
||||
|
||||
Reference in New Issue
Block a user