nodejs テスト 記事下書き

• 知りたかったこと
  テストのプラクティスを調べてもTDDとかしか出てこない。TDD知ったっていざ作るときに疑問が出てくる
• どこからテストを書き始めたらいいのか
  • 例えばHoge機能を作りたいと思いバックエンドから着手するとする。
    • まずどこから作る？
      • controller
      • model
      • db(migration)
      • service
    • どのテストをつくる？
      • controllerとかserviceのテスト書いたけどモデルにほぼロジック乗ってるからテストすることがない？？(逆もありそう)
      • dbのテストってどうすればいいの？
• どこまで検証すべきか
  • APIテストであれば何を検証すべきなのか
    • ステータスコード？
    • レスポンス？
    • DBの値？

学べば学ぶほどわからなくなる

• 基礎
  • ピラミッド
  • ホワイトボックステストとブラックボックステスト
  • プログラマとテスターの役割

テストに対する考え方の違い

機能の保障としてのテストという考え方 (テストケース)
コード設計ツールとしてのテストという考え方 (TDD, BDD)

テストの目的

• 回帰テスト
• 負荷(性能)テスト
• セキュリティテスト

テストの実施方法

• テストケースを一通り揃える虱潰し型のテスト
• モンキーテストや探索テストとして経験値に基づく発見型のテスト

１つのテストがカバーする範囲(テストレベル)

• UIテスト、E2Eテスト
• 統合テスト(APIテスト)
• 単体テスト

実際のテストケースの書き方のパターン

• 境界値テスト
• 同値テスト
• 正常系
• 異常系
• ブラックボックステスト
• ホワイトボックステスト

テストのメリット

機能保証としてのテストの場合

• サービスの利用保証
  • バグの早期発見

開発手法としてのテストの場合

• テストありきのコードが書ける。結果的にコードの保守性が上がる
• 完成したテストは機能保証としてのテストの役割も負うことができる (回帰テスト、機能テストとしての役割)

テストのデメリット

• コードに対する依存になる。コード変更するとテストも壊れる可能性がある。どの程度壊れるかは依存度による。
• 実装と同じくらいもしくはそれ以上に時間がかかる可能性がある
• テストの経験豊富な開発者が少ない
• 最初からテストが想定されていないコードに対してはテストがしにくい

今まで疑問に思ってきたことは

どの範囲をどこまでテストすればよいのかということだった。

コラム
it()には何を書くべきか

理解

これからは開発者はTDDで機能テスト(回帰テスト)を作成し、テスターは探索テストで発見型のテストを行うような流れになっていきそう。

受け入れテストは開発プロセスによっては必要ない(受け入れ側が開発サイドではないときに行われる事が多い。もしくは受け入れ側が積極的に開発に関わっていれば、わざわざテストというイベントを用意せずともデモの共有だけで納得できたりする)

プラクティス

テストもコードの一部であるという意識。

テスト環境編

• バックエンドはステートフルでかなり依存ミドルウェアが多い(DBなど)のでdockerとdocker-composeで構築する
  • 基本的に普段の開発はdocker上で行う。さもないとテストCIだけdockerを利用しているとdockerが壊れたときに２度手間になる
• CI/CDサービスはdockerが使えるものを選択する

テストレベル編

• ユニットテストから始めることが望ましいがコードの書き方によってはそのモジュールやクラスがテストしにくくできていたりかなり依存が多かったりとユニットテストが難しい可能性がある。テスト文化を導入するにはAPIテストからやったほうがやりやすく効果的だったりする。最初はAPIテストから取り入れてみる。
• テストピラミッドの下の方から充実させていくことは知識として持っておく

テストケース編

• BDDのテストの書き方(describeやwhenやitなど)を学ぶ
• 正常系(晴れの日のシナリオ)と異常系(雨の日のシナリオ)を考える
• 異常系では境界値テストなどの利用する
• 単体テストで複数のメソッドをもつクラスをテストするときpublicなメソッドのみテストを行う。
• 基本メソッド内の実装の中身は触れずにそのインターフェースのみテストする(ブラックボックステスト)
  • そのメソッドないで〇〇の値が変化してほしいなどのホワイトボックス的なテストをしたいときがある。そのときはその値を変化させるクラスをDIしてそいつをspyやmockなどで値を追う
• 3A(arrange, act, assert)から初めてみる
• テストフィクスチャはチーム開発では壊れやすいので使わない。テストデータはその都度arrangeやbefore内で用意する
  • テストデータを用意するためのヘルパーメソッド(builderやfactory)を充実させる。
• Repositoryパターンを利用しているアーキテクチャはテストデータを用意するさいにはそのRepositoryを使う。
• テストのitの書き方
  • 日本語でおk
  • 正常系なのか異常系なのかひと目でわかるように
    • expectにも詳細文章を書く

テストフレームワーク編

• BDDの書き方ができればOK
• 並行テストができるフレームワークとできないフレームワークがある

セキュリティ編

• 利用しているライブラリの脆弱性はdockerなどを利用している場合はイメージスキャンサービスをCI(CD)の中に取り込むこともできる
• セキュリティは外部の脆弱性診断を利用したり(結構高い)、もしくは普段からセキュリティの知識を身につけることで対応する