@@ -3,7 +3,7 @@ id: testing-overview
3
3
title : Testing
4
4
author : Vojtech Novak
5
5
authorURL : ' https://twitter.com/vonovak'
6
- description : このガイドではReact Native開発者に良いテストの書き方やどのようなテストを取り入れるべきかという、テストのキーコンセプト概念を紹介します 。
6
+ description : このガイドではReact Native開発者に良いテストの書き方やどのようなテストを取り入れるべきかという、キーコンセプトを紹介します 。
7
7
---
8
8
9
9
コードが大きくなるにつれて、予期しない小さなエラーやエッジケースが大きなエラーに繋がることがあります。バグは悪いユーザーエクスペリエンスとなり、究極的にはビジネス機会の損失になり得ます。脆弱なプログラミングを防ぐ方法の 1 つはリリースをする前にコードのテストを行うことです。
@@ -20,32 +20,32 @@ description: このガイドではReact Native開発者に良いテストの書
20
20
21
21
テストは新しくチームに入った人へドキュメントを提供する事にもなります。実際のコードを見た事がない人でもテストを読む事によって既存のコードがどのように動くか理解しやすくなります。
22
22
23
- 最後になりますが大事なことに、テストが自動化されるにつれて手動で<abbr title =" Quality Assurance " >QA</abbr >テストをする時間が少なくなり 、貴重な時間を開放できます。
23
+ 最後になりますが大事なことに、テストが自動化されるにつれて手動で<abbr title =" Quality Assurance " >QA</abbr >テストをすることにかかる時間が少なくなり 、貴重な時間を開放できます。
24
24
25
25
## 静的解析
26
26
27
27
コード品質改善の最初の一歩として、静的解析ツールを使いましょう。静的解析はコードを書くとコードを全く動かすことなくエラーを調べてくれます。
28
28
29
29
- ** Linters** コードを解析すると使われていないコードを見つけたり、スペースの代わりに tab を使っている(設定次第ではその逆もあります)といった、スタイルガイドが禁止している書き方を見つけることができます。
30
- - ** Type checking** は、 number 型が渡されることを期待している counting 関数に対して string が渡されるのを防ぐといったように、関数に渡しているデータ構造が関数によってあらかじめ設計されているものと一致している事を保証します。
30
+ - ** Type checking** number 型が渡されることを期待している counting 関数に対して string が渡されるのを防ぐといったように、関数に渡しているデータ構造が関数によってあらかじめ設計されているものと一致している事を保証します。
31
31
32
32
React Native はすぐに使える設定済みの二種類のツールがあります。: [ ESLint] ( https://eslint.org/ ) ` lint ` のためのツールです。[ Flow] ( https://flow.org/en/docs/ ) または、 [ TypeScript] ( typescript ) (JavaScript にトランスパイル可能な型付き言語)、` Type checking ` のためのツールです。
33
33
34
34
## テストのしやすいコードを書くこと
35
35
36
36
テストを始めるにあたって、まず最初に必要なことはテストのしやすいコードを書くことです。航空機を作るプロセスを考えてみてください。 - いかなるモデルの機体でも、複雑なシステムが相互に全て正しく動いているかを確認するために飛ばしますが、それ以前に個々のパーツではテストが行われ安全であり正しく機能している事が保証されます。例えば翼は著しく重い負荷によって曲がるかをテストし、エンジンのパーツは耐久性をテストし、フロントガラスはバードインパクトをシミュレートしたテストがされます。
37
37
38
- ソフトウェアも似ています。全体のプログラムをたくさんの行のコードを巨大な 1 つのファイルへ書く代わりに、組み立てられたコード全体をテストする事よりも徹底的にテストが可能な小さな複数のモジュールとしてコードを書きます。この意味で、テストのしやすいコードは簡潔かつモジュラーに組み合わされています 。
38
+ ソフトウェアも似ています。全体のプログラムをたくさんの行からなる巨大な 1 つのファイルとして書く代わりに、全体をテストするよりもより徹底してテストを行える小さなモジュールとしてコードを書きます。このようにして、テストをしやすいコードを書くということは、簡潔かつもジューラーなコードを書くこととなります 。
39
39
40
- アプリケーションをよりテストしやすくするには、React のコンポーネントのビューをロジックとステートに切り離すことから始めましょう。 (Redux, MobX その他どのようなソリューションを用いるとしてもです。) このようにして、ビジネスロジックに関するテストを主にアプリケーションの UI 描画が責務となる React コンポーネントから独立に保つことができます 。
40
+ アプリケーションをよりテストしやすくするには、React のコンポーネントのビューをロジックとステートに切り離すことから始めましょう。 (Redux, MobX その他どのようなソリューションを用いるとしてもです。) このようにして、Reactコンポーネントに依存してはいけないビジネスロジックのテストと、主にアプリケーションのUIをレンダリングすることが責務となるコンポーネントの独立性を保つことができます 。
41
41
42
42
理論的には、全てのロジックとデータの取得をコンポーネントから移動させることができるはずです。こうすれば、コンポーネントは単独でレンダリングに注力されます。ステートは全体的にコンポーネントから独立するでしょう。アプリケーションのロジックはコンポーネントが一切存在しなくても動くはずです。
43
43
44
44
> 他の学習資料についてもテスタブルなコードについての話題をより深く調べてみることもお勧めします。
45
45
46
46
## テストを書く
47
47
48
- テストを描きやすいコードを書いた次に、実際にいくつかテストを書いてみましょう。 React Native の初期状態のテンプレートは[ Jest] ( https://jestjs.io ) テストフレームワークを搭載しています。テンプレートは、モックや設定に悩まなくてもストレートな道筋であなたを生産的にするように、事前に環境が仕立てられたプリセットを含んでいます- [ モックをより詳しく ] ( #mocking ) 。このガイド上のあらゆる種類の機能テストは Jest を使います 。
48
+ テストを描きやすいコードを書いた次に、実際にいくつかテストを書いてみましょう。 React Native の初期状態のテンプレートは[ Jest] ( https://jestjs.io ) テストフレームワークを搭載しています。これにはこの環境に適したプリセットが含まれているので、configやモックを調整ぜずに生産的なテストを行うことができます [ more on mocks ] ( #moching ) 。Jestを使用してこのガイドで取り上げられている全てのタイプのテストを行うことができます 。
49
49
50
50
> テスト駆動開発をするなら、テストを最初に書きます。そうすれば、テスタビリティがコードに与えられます。
51
51
@@ -67,7 +67,7 @@ it('given a date in the past, colorForDueDate() returns red', () => {
67
67
68
68
これらはまた AAA(Arrange, Act, Assert)としても知られています。
69
69
70
- Jest はテストを構成するのを助ける [ ` describe ` ] ( https://jestjs.io/docs/en/api#describename-fn ) 関数を提供します。1 つの機能性に属する全てのテストをグループにまとめるのに ` describe ` を使用してください。describe 関数は必要であればネストして構いません。その他の関数でよく使われるものには[ ` beforeEach ` ] ( https://jestjs.io/docs/en/api#beforeeachfn-timeout ) や [ ` beforeAll ` ] ( https://jestjs.io/docs/en/api#beforeallfn-timeout ) があり、あなたがテストしたいオブジェクトの設定をするために使えます。より詳しくは [ Jest api reference] ( https://jestjs.io/docs/en/api ) を読んでください。
70
+ Jest はテストを構成するのを助ける [ ` describe ` ] ( https://jestjs.io/docs/en/api#describename-fn ) 関数を提供します。1 つの機能性に属する全てのテストをグループにまとめるのに ` describe ` を使用してください。describe 関数は必要であればネストして構いません。その他の関数でよく使われるものには[ ` beforeEach ` ] ( https://jestjs.io/docs/en/api#beforeeachfn-timeout ) や [ ` beforeAll ` ] ( https://jestjs.io/docs/en/api#beforeallfn-timeout ) があり、テストしたいオブジェクトの設定をするために使えます。詳細は [ Jest api reference] ( https://jestjs.io/docs/en/api ) を読んでください。
71
71
72
72
もしテストが多くのステップ、多くの結果をテストする時に、もっと小さくそれらを分けたくなるでしょう。そのようであれば、あなたのテストケースは他の機能から完全に独立することを保証してください。テストスイートの中のそれぞれのテストは他のテストケースが走り始めなくても、単体で実行できるようにしなければなりません。逆の見方をすると、全てのテストを一度に行う場合は、最初のテストが次のテストの結果に影響を与えてはいけません。
73
73
@@ -101,11 +101,11 @@ Jest はテストを構成するのを助ける [`describe`](https://jestjs.io/d
101
101
102
102
## 統合テスト
103
103
104
- 大きなソフトウェアシステムを書く時、個々のプログラムが相互にやりとりする必要があります。単体テストではあるプログラムが他のプログラムに依存していても、たびたび、それらを最終的にフェイクに置き換えて依存をモックにします 。
104
+ 大きなソフトウェアシステムを書く時、個々のプログラムが相互にやりとりする必要があります。単体テストではあるプログラムが他のプログラムに依存していても、その依存をモックにしフェイクに置き換えることがありました 。
105
105
106
106
統合テストでは、実際の個々のユニットを組み合わせて(実際のアプリケーションと同じように)それらが期待通りに協調して動くことを保証するためのテストをまとめて行います。だからと言って、モッキングが必要でなくなるわけではありません。まだモック(例えば、天気情報の通信のモック)を必要とするかもしれませんが、単体テストの時より必要とする機会はずっと少ないでしょう。
107
107
108
- > 統合テストに関する用語の意味は必ずしも一貫性があるものではないことに注意してください。また、単体テストと統合テストの境界はいつでも明確とは限りません。このガイドにとってあなたのテストが統合テストを意味する時はテストが以下のような時です 。
108
+ > 統合テストに関する用語の意味は必ずしも一貫性があるものではないことに注意してください。また、単体テストと統合テストの境界はいつでも明確とは限りません。このガイドでは、テストが以下のような時に統合テストに分類することとします 。
109
109
110
110
> - 先に述べたようにアプリケーションにおける複数のモジュールが結合している時
111
111
> - 外部のシステムを使っている時
@@ -172,7 +172,7 @@ function GroceryShoppingList() {
172
172
173
173
経験則としてユーザーが、見ることができるもの、聞くことができるものを使う事が好ましいです。
174
174
175
- - 書かれている文字や[ accessibility helpers] ( https://reactnative.dev/docs/accessibility#accessibility-properties ) にアサーションを行う
175
+ - 書かれている文字や[ accessibility helpers] ( https://reactnative.dev/docs/accessibility#accessibility-properties ) を使用してアサーションを作成する
176
176
177
177
逆に避けるべき事は以下の通りです。
178
178
@@ -252,13 +252,13 @@ E2E テストはアプリケーションが部分的に動く事について最
252
252
253
253
E2E テストはアプリケーションにとって生命線となる機能で使ってください。: 認証のフロー、重要な機能、決済、などです。アプリケーションの死活にかかわらない機能はより速い JS のテストを使いましょう。テストを増やすに連れて信頼性は増しますが、メンテナンスやテストの実行により多くの時間をかけることにもなります。トレードオフを考えながらあなたにとって何がベストであるかを決めてください。
254
254
255
- E2E テストに利用できるツールは複数あります。: React Native Community においては、[ Detox] ( https://github.com/wix/detox/ ) が人気のフレームワークで React Native のアプリケーションのために利用できます 。その他にも iOS や Android アプリケーションにおいて人気のあるライブラリとして[ Appium] ( http://appium.io/ ) があります。
255
+ E2E テストに利用できるツールは複数あります。: React Native Community においては、React Native用に調整されているので [ Detox] ( https://github.com/wix/detox/ ) が人気のフレームワークです 。その他にも iOS や Android アプリケーションにおいて人気のあるライブラリとして[ Appium] ( http://appium.io/ ) があります。
256
256
257
257
<img src =" /docs/assets/p_tests-e2e.svg " alt =" " />
258
258
259
259
## サマリー
260
260
261
- 私たちはあなたがこのガイドを読んで何かを学び楽しんでくれたことを願います 。アプリケーションをテストできるたくさん方法があります。何を最初に使えばいいか決めるのは難しいこともあります。しかしながら、その全てがあなたの素晴らしい React Native のアプリケーションへ加わった途端に役に立つと信じています 。何を待つことがあるでしょうか。 今すぐテストカバレッジを上げていきましょう。
261
+ 私たちはこのガイドを読んで何かを学び楽しんでくれたことを願います 。アプリケーションをテストできるたくさん方法があります。何を最初に使えばいいか決めるのは難しいこともあります。しかしながら、ひとたびReact Nativeアプリケーションにテストが加わると、その全てが意味をなすようになると私たちは信じています 。何を待つことがあるでしょうか? 今すぐテストカバレッジを上げていきましょう。
262
262
263
263
### Links
264
264
0 commit comments