skillup

技術ブログ

アーキテクト設計全般 プログラミング全般 プロジェクト管理

自動テストをやる上で今まで障害だったこと

投稿日:2022年10月8日 更新日:

自動テストについて、考え方自体は5年以上前から知っていましたが、プロジェクトで実際に使われているのを見たのは今年4月になってからでした・・・

自動テスト完備なんて昔は夢物語だと思ってたんですけどね・・・

昔なぜ自動テストができないと思ったか(そして現在のプロジェクトはいかにそれを実現しているか)を列挙していきたいと思います。

ちなみに全テストを実行するまでに許容できる時間は5〜10分とします。

DBの初期化

一番はこれですね・・・今まで自動テストやるのに最大の関門はDB系のテストでした。

DBのテストをする場合、テスト用のDBを用意していたりしたんですが、どうしてもテストのたびにデータが変わってしまってテストの担保ができません。

時間経つとExcelを引っ張り出して最初からいちいち作り直しみたいなことをやってました。

DBのテストを実行する場合、理想的には関数ごとにテーブルデータ初期化(つまりはmigrationを都度行う)が必要になります。

ですので、migrationが必ず完備されており、テストのたびに新規のテーブルが作れればOKです。

これだけでテストができなかった7割ぐらいの問題は解決しました。

Laravelですとuse RefreshDatabase;というコマンドでテストのたびにmigration実行させることができます。

【Laravel】PHPUnitの実行でDBを汚染しないためにできる簡単なこと

テストデータ作成

DBの初期化とセットのような内容ですが、テストの場合、テストそのものよりはデータの用意に時間がかかることが圧倒的に多いです。

そのため、テストのたびに前提となるテストデータがすぐに作れるか。

そしてテストデータを作りやすいようにそれ用のメソッド(Laravelだとfactoryメソッド)が用意されていることが大前提になります。

データ量の制限

次に最低限の稼働をさせるDBの量がそもそも少ないというのが大事かと思います。

テストのたびに初期化をするのでその度に大量のデータを入れるようなものばかりだと時間が大幅にかかってしまいます。

マスタ系のデータでしたらできればレコード量を100以下にしないとそもそも時間がかかってしまって現実的でないと思います。

(どうしても大量データがある場合は通常時はskipさせるなどの処置が必要かと思います。)

外部連携

次に自動テストが難しいと思ったのは外部のサービスですね。具体的にはAPI連携やAWS系のサービスです(例えばS3など)。

今のプロジェクトでAPI連携はないのですが、これはDIを使い、ローカル時にはJSONファイルなどで対応させるのが一番かと思います。

AWS系のサービスではlocalstackなどテスト用の仮想環境を使うのがいいでしょう(phpunitをdockerで実行させることになりますが・・・)。

またそもそもラッピングしたメソッドを用意し、DIで代用しても良いかもしれません・・・

複雑なm×nパターン

バリデーションなどが一般的ですがパターン数が多くなる場合、それ用のメソッドを整備しないとコードの量がめちゃくちゃ増えちゃいます。

そこで、ケースを配列などで用意しておき、それを読み込む特定のメソッドなどを用意しておくと良いでしょう。

LaravelですとdataProviderという仕組みがあり、複数のパターンが用意に作れます。

dataProviderの書き方

テストコードを書くコスト

技術的なことではなく、政治的なことにもなりますが、そもそもテストコード自体を許可してもらえるか、ということです。

長い目で見れば少しの修正のたびに手動での確認というのは手間が天文学的になるので、カバレッジ100%を目指さなくてもざっくりとテストコードはあったほうがいいと思いますが、短期的には成果物の進捗にはマイナスになります。

そこで、プロジェクトでテストコードを書く手間を許容できるか・・というのがまずプロジェクトを始める上での最初の関門になるかと思います。

-アーキテクト設計全般, プログラミング全般, プロジェクト管理
-,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

APIのエラーコードに関して

APIのよく使われるHTTPステータスコードに関して。 基礎の基礎で当たり前に使ってましたが、基本的なことに関してまとめ。 主に4XXエラーのタイプ分けに関して。 Contents1 2002 201 …

no image

メモリに関して 静的領域、スタック、ヒープなど

実務でメモリの調査をしましたが、肝心のメモリについてほとんどわかっていないのでメモ。 メモリの領域を大きく分けると静的、スタック、ヒープに別れる。 Contents1 静的2 スタック3 ヒープ4 そ …

no image

画面の制御フローなど

複雑な帳票系アプリではよくあると思うのですが、ある入力値が複数の場所から影響を受けており、制御がなかなか難しいときなどがあります。 例として クリアボタンなどでクリアされる 他のプルダウンなどで影響を …

no image

オブジェクト指向 プレゼンテーション層

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。 Contents1 プレゼンテーション層の考え方1.1 要点1. …

no image

文化づくりについて(チームビルディングに関して)

プロジェクトやチームの文化づくりについて。 エンジニアに限らず塾運営スタッフ時代から感じていたことなどを。 全く同じ仕事をしていても職場の文化というのは全く違うもので、ある場所で当たり前なことが別の場 …

アーカイブ