テストについてのリファレンス(全般 -> Vue)
後半ほど重要度が高い
ALL
-
テスト仕様書
- テストの種類
- 単体テスト
- 結合テスト
- 機能テスト
- システムテスト(負荷テスト、ボリュームテスト、セキュリティテストetc)
- 受け入れテスト(シナリオテスト)
- 運用テスト
- リグレッションテスト
- ①テスト計画
- ②テスト設計
- ③テスト仕様書
- テストの種類
-
テスト自動化について、調べてみた
- テストの種類
- 単体テスト
- 各moduleの機能を満たしているかを確認するテスト
- 基本的にホワイトボックステスト
- メソッド毎
- 他のmoduleに依存する部分はstub,mock化してテスト
- 結合テスト
- 各moduleを連結してテストする
- 外部APIなどの外部接続するものテストを段階的に行う場合も
- 基本的にブラックボックステスト、場合によってホワイトボックステスト
- 複数のmoduleを合わせてプログラムが要件を満たしているか
- 各module(外部APIやDB部分)が連結する部分も合わせて
- 総合テスト(UIテスト)
- 外部APIやブラウザなど全ての条件を結合するテスト
- 要件通りに動作するかを確認
- 基本的にブラックボックステスト
- 単体テスト
- テストの観点
- 機能要件
- クライアント要件を満たす部分
- テストコードで担保できる部分
- 非機能要件
- 情報セキュリティ
- パフォーマンスetc
- 機能要件
- テストコードの重要度は一般的に 単体テスト > 機能テスト > UIテストの順
- テストの種類
-
若手プロマネの羅針盤
- 単体テスト・結合テスト・総合テストの違い
- 単体テスト
- 結合テスト
- 内部結合テストと外部結合テストの違い
- 総合テスト
- テスト結果報告について
- 単体テスト・結合テスト・総合テストの違い
Frontend
-
JavaScript開発のためのテスト入門第1回 テストとはなにか
- 記述したテストケースが間違いなく動作することを保証するもの
-
- テストの種類
- 単体テスト: 入力をモック化し、個々の関数やクラスをテストし、出力結果が予想通りであることを確認するテスト
- 結合テスト: いくつかのモジュールを組み合わせて予想通りに動作することを保証するテスト
- 機能テスト: 製品自体を使って(例えばブラウザを使って)、あるシナリオをテスト
- テストツールの種類
- テストの環境を提供する(Mocha、Jasmine、Jest、Karma)
- テストの構造を提供する(Mocha、Jasmine、Jest、Cucumber)
- アサーション機能を提供する(Chai、Jasmine、Jest、Unexpected)
- 生成、表示、テスト結果をウォッチする(Mocha、Jasmine、Jest、Karma)
- スナップショットを比較する(Jest、Ava)
- モック、スパイ、スタブを提供する(Sinon、Jasmine、enzyme、 Jest、testdouble]
- コードカバレッジのレポートを生成する(Istanbul、 Jest)
- シナリオ実行の管理ができるブラウザ、または疑似ブラウザの環境を提供する(Protractor、Nightwatch、Phantom、Casper)
- 上記の用語説明(アサーション, スパイ, スタブ, モック)
- テストの種類
-
- jest選択理由
- ①機能豊富、設定用意
- ②ウォッチモードで起動すると、ファイル変更時に依存関係のあるテストだけ走る
- ③スナップショットテスト
- ④import/require をモックする必要がなくなった
- jestデメリット
- Benchmark.js と組み合わせるとこける
- TypeScript から使おうとすると追加のパッケージ + お約束の config がいる。mocha と比べると少しだけ手間が大きい
- 全般にエコシステムが未成熟
- jest選択理由
-
Facebook製のJavaScriptテストツール「Jest」の逆引き使用例
- セットアップ
- テスト構文 (describe, it, ...etc)
- テストマッチャー (.toBe(), .not, ...etc)
- promise (resolve, rejectの検証)
- モック (mockImplementation, mockImplementationOnce)
Vue
-
- おすすめは、Karma と、そのプラグインの CommonJS pre-processor を使用して、テストを実行する方法
- Vue.js のディレクティブは、非同期でデータ更新に反応するので、データ更新後の DOM ステータスに対してアサーションを行うには、Vue.nextTick のコールバックを利用する必要があります。
-
- テストしやすいコンポーネント
- 機能が少ない(メソッド数ではなく、担う役割)
- 依存がない/少ない
- 状態をもたない
- ライフサイクルフックに直接処理を書かない
- Presentational Component と Container Component
- なにをテストするか
- templateで次の項目が正しく動作するか
- 正しくレンダリングされるか
- v-on
- v-bind:props
- v-bind:attes
- propsが正しく受け取れるか
- methodsが正しく動作するか
- $emitでイベントが正しく発火するか
- slotが正しく動作するか
- コンポーネント同士が正しく協調しているか
- templateで次の項目が正しく動作するか
- テストしやすいコンポーネント
Vuex
導入観点
- 導入しながら下記の観点で試行錯誤する
テストライブラリ
下記の理由でjest採用
- 実DOMでの表示以外を網羅している(実DOM表示は、karma, StoryBook導入で補える?)
- パフォーマンスも他と大差ない
- 公式リファレンスが豊富
- 導入、設定も比較的容易
Componentのテストって単体テスト?結合テスト?
- クラスベース言語のClass, functionの粒度問題と同じ
- Atomic Designのatomなら単体テストとして捉えられそう
(関数: Component全体, 引数: props, VuexState, 返り値: DOM, emit)
単体テスト vs 結合テスト
- どちらかといえば、要件を満たせているのか?(結合テスト)の方が重要だろう
そのサービスの中で重要度を考える
- 重要度に合わせて、結合テストのみ、結合テスト&単体テストを考慮
リファクタする範囲をテスト
密結合や粒度の大きいfunction, componentをリファクタするなら、テストを書いてから実施
今ままで発生している不具合、仕様検討もれから検討
- その不具合を発生させない(気づく)ために必要だったテストを実装
- 今後も、不具合、使用検討もれが発覚したらば、再発防止用のテストを実装(要検討)
メンテナンスコスト
- 実コードを修正するたびにテストコードを変更する必要があることも考慮(単体テストがより生じやすい?)
- そもそも変更しなくて済むテストコードもありでは