テスタビリティが下がる場合と上がる場合をメモする
テスタビリティが下がるのは、依存関係が多い時にテスタビリティが下がる。
不要な依存は増やさないようにすること
不要な依存とはfatな機能から発生する。
テスタビリティが下がる行為２
高結合なオブジェクトを使用してファクトリメソッドを作る。
テストする際に無駄な値を設定してテストする必要があり、テスト容易性が下がる
テスタビリティが下がる行為3
データベースをCI/CDでテストする際に様々なデータが入ったDBのテストを各機能開発者が同時期に開発を行い、DBの初期化などのタイミングの問題でテストが失敗する状態。テスト容易性が下がる。
マイクロサービスアーキテクチャの要素の一つDBの分割や、dockerを使った試験を行う環境作りが大切になる。
テスタビリティが下がる行為4
画面の入力項目数が多い時はテストがしにくい
テスタビリティが下がる行為5
企画検索画面色々なテーブルから情報を引っ張るところがある
ここのテストをすることが難しい。
解決策:DBを分割->各サービスで取得して各テーブルのテストを指せない。
解決策:DBユニット->DbUnitを使う
番外編-人間編1
DBUnit学習が必要
テスト仕様書を丁寧に書いたり、
このシステムを知らない人でもできるようにすること。
そもそもランニングコストが高い？
戻り値があるとテストしやすい
