RDBを使う単体テストの前に 用意しておきたい環境を考え てみたの

JaSST nano vol.30( https://jasst-nano.connpass.com/event/300947/ )で登壇した内容です。

とても基本的なこともあえて述べています。DBは開発者個別に用意してあげましょう。

Transcript

1. RDBを使う単体テストの前に 用意しておきたい環境を考え てみたの やめて！私のために争わないで！？
2. みなさん、自動テストしてますか？ （ご挨拶
3. 自己紹介 ＞ クラスメソッド株式会社 開発3年、クラウドエンジニア2年 先日JSTQB FL合格しました ＞ 経歴 ダイの大冒険 ＞ 好きなもの モダンアプリケーションコンサルティング部 ＞名前 bun913（今泉大樹）
4. 私の立場と話すこと ＞ 領域 アジャイル開発を想定しています ＞ 開発手法 ＞ テストレベル Webアプリケーションが主領域（AWS、バックエンド開発、ちょっとフロントエンド） ＞立場 開発に近い立場として、テストやQAについて真剣に考えています 単体・（コンポーネントレベル）統合テスト
5. 最近 JSTQB テストマネージャ 試験の学習をしています
6. テスト計画 テストのプロセス テスト分析 テスト設計 テスト実装 テスト実行 終了に向けて ※「終了基準の評価とレポート」などがJSTQB テストマネージャのシラバスに記載されています https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf
7. テスト環境づくりもマネージャの仕事 > テスト実装には、テストチームがテスト実行を 開始する準備が整っていることの最終チェックも 含む。このチェックには、必要なテスト環境、テ ストデータ、テストコードが整っていることの確 認（省略）およびすべてのテストケースを記述 し、レビューし、実行の準備が整っていることの 確認を含む。 ※シラバスp13より（前ページと同じ出典のためリンクは省略）
8. アジャイルの場合、開発者が単体・統合 テストを実装・実行することが多い
9. １人の開発者目線で RDBを使う環境におけるテスト環境 について語ります
10. 3つの競合を回避できる環境づくり サブタイトルの「争わないで」を回収しています
11. １. 他の開発者との競合
12. 開発用のDBくんだよ 仲良くしてあげてね まれにある状況 偉い人 共用DB
13. こういう状態 共用DB 変更 変更 変更
14. こうなる あいつのテーブル変更の せいでテスト通らない あいつがテーブルに変な データ入れた！
15. つまりこう やめて私のために争わな いで！ 共用DB
16. コンテナ仮想技術がおすすめ DockerやPodmanなど、コンテナ用のツー ル・サービスを利用しましょう MySQL・PostgreSQLなどのDBMSを少ないオ ーバーヘッドで起動できます 個々の開発者がどんどん壊せる環境を用意し ましょう。セットアップも簡単！
17. 2. 他のテストケースとの競合
18. DBを個別に用意するだけでは （個人的に）ちょっと足りない
19. テストケースを記載中（単体テストの自動化） （前処理）テストユーザー作成（user1） テストユーザーログイン成功 テストユーザーログアウト成功 開発者A
20. こんなこともあるでしょう 開発者Aの作ったレコードと ユニーク制約で競合する 適当にuser2とかするか 開発者Aの作ったレコードと ユニーク制約で競合する 適当にuser2とかするか 開発者B 開発者C
21. テストケースのソースコードは当然共有 他のテストケースや順番を考えたくない →テストケース間で隔離された環境が欲しい
22. やめて！わたしのために(略） つまりこう
23. 各テストケースの後処理でデータ消せば いいだけじゃないの？
24. こんなこと考えられませんか？ テストツールがテストケースを並行実行でき るなら？ 後処理前に他のテストケースが実行される どこかで途中でテストが終了したら？ 後処理しないテストデータが残る （リセットしないと）次のテスト実行が失 敗する
25. トランザクショナルな仕組みを活用したい DBMSのトランザクション機能をいい感じに使 って、他のテストケースと隔離される テストケースが終わったらロールバック 途中で失敗してもコミットされてない テストケース間でのDB操作がお互いに影響し ない RSpec: use_transactional_fixtures Spring: @Transactional アノテーション
26. PrismaとJest環境の場合
27. 3. 過去の自分の操作との競合
28. ここまでの対策で十分なのか？ 本当の敵は自分自身なんじゃないの？
29. ID name email(Unique) hogefuga test hoge@example.com 開発者A ローカルでちょっとした動作確認を行う Post /users データ作成
30. ID name email(Unique) hogefuga test hoge@example.com fugafuag test_user hoge@example.com テストケースでも同じようなレコードを作成していた （前処理）テストユーザー作成（test_user） テストユーザーログイン成功 テストユーザーログアウト成功 ユニーク制約でレコード作成失敗 テストケースの実行も失敗
31. やめ（略）わた（略） つまりこう ５分前に動作確認でDBレコードを作った自分自身
32. Ruby on Railsなどでは・・・ ローカルでの開発時とテスト時で接続するDB を変更できる
33. とはいえ考えるべきことも・・・ テスト実行前にテスト用DBにもDBマイグレー ションを適用する必要がある テスト実行時に環境変数を読み込ませるな ど、テスト用DBに接続しにいける準備が必要 そもそも、そこまでする必要があるのか？ 発生してもDBリセットや辻褄合わせすれ ばよい（許容できるか）
34. まとめ 開発者に気持ちよくRDBが絡むテストを書いてもらうために考えていること
35. テスト作成ハードルを下げるために３つの競合を意識 １他の開発者との競合 個別のDBインスタンスやDockerコンテナ 2 テストケース間での競合 トランザクショナルな仕組み 3 ローカルでの自分自身のオペレーションとの競合 （テスト外で作ったデータなど） テストとローカル動作確認用のDBを分ける 個人的に1と2は必須レベルで欲しい
36. テストを書く心理的ハードル を少しでも下げたい
37. ご清聴ありがとうございました