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

by bun

Slide 1

Slide 1 text

RDBを使う単体テストの前に用意しておきたい環境を考えてみたのやめて！私のために争わないで！？

Slide 2

Slide 2 text

みなさん、自動テストしてますか？（ご挨拶

Slide 3

Slide 3 text

自己紹介＞クラスメソッド株式会社開発3年、クラウドエンジニア2年先日JSTQB FL合格しました＞経歴ダイの大冒険＞好きなものモダンアプリケーションコンサルティング部＞名前 bun913（今泉大樹）

Slide 4

Slide 4 text

私の立場と話すこと＞領域アジャイル開発を想定しています＞開発手法＞テストレベル Webアプリケーションが主領域（AWS、バックエンド開発、ちょっとフロントエンド）＞立場開発に近い立場として、テストやQAについて真剣に考えています単体・（コンポーネントレベル）統合テスト

Slide 5

Slide 5 text

最近 JSTQB テストマネージャ試験の学習をしています

Slide 6

Slide 6 text

テスト計画テストのプロセステスト分析テスト設計テスト実装テスト実行終了に向けて ※「終了基準の評価とレポート」などがJSTQB テストマネージャのシラバスに記載されています https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf

Slide 7

Slide 7 text

テスト環境づくりもマネージャの仕事 > テスト実装には、テストチームがテスト実行を開始する準備が整っていることの最終チェックも含む。このチェックには、必要なテスト環境、テストデータ、テストコードが整っていることの確認（省略）およびすべてのテストケースを記述し、レビューし、実行の準備が整っていることの確認を含む。 ※シラバスp13より（前ページと同じ出典のためリンクは省略）

Slide 8

Slide 8 text

アジャイルの場合、開発者が単体・統合テストを実装・実行することが多い

Slide 9

Slide 9 text

１人の開発者目線で RDBを使う環境におけるテスト環境について語ります

Slide 10

Slide 10 text

3つの競合を回避できる環境づくりサブタイトルの「争わないで」を回収しています

Slide 11

Slide 11 text

１. 他の開発者との競合

Slide 12

Slide 12 text

開発用のDBくんだよ仲良くしてあげてねまれにある状況偉い人共用DB

Slide 13

Slide 13 text

こういう状態共用DB 変更変更変更

Slide 14

Slide 14 text

こうなるあいつのテーブル変更のせいでテスト通らないあいつがテーブルに変なデータ入れた！

Slide 15

Slide 15 text

つまりこうやめて私のために争わないで！共用DB

Slide 16

Slide 16 text

コンテナ仮想技術がおすすめ DockerやPodmanなど、コンテナ用のツール・サービスを利用しましょう MySQL・PostgreSQLなどのDBMSを少ないオーバーヘッドで起動できます個々の開発者がどんどん壊せる環境を用意しましょう。セットアップも簡単！

Slide 17

Slide 17 text

2. 他のテストケースとの競合

Slide 18

Slide 18 text

DBを個別に用意するだけでは（個人的に）ちょっと足りない

Slide 19

Slide 19 text

テストケースを記載中（単体テストの自動化）（前処理）テストユーザー作成（user1）テストユーザーログイン成功テストユーザーログアウト成功開発者A

Slide 20

Slide 20 text

こんなこともあるでしょう開発者Aの作ったレコードとユニーク制約で競合する適当にuser2とかするか開発者Aの作ったレコードとユニーク制約で競合する適当にuser2とかするか開発者B 開発者C

Slide 21

Slide 21 text

テストケースのソースコードは当然共有他のテストケースや順番を考えたくない →テストケース間で隔離された環境が欲しい

Slide 22

Slide 22 text

やめて！わたしのために(略）つまりこう

Slide 23

Slide 23 text

各テストケースの後処理でデータ消せばいいだけじゃないの？

Slide 24

Slide 24 text

こんなこと考えられませんか？テストツールがテストケースを並行実行できるなら？後処理前に他のテストケースが実行されるどこかで途中でテストが終了したら？後処理しないテストデータが残る（リセットしないと）次のテスト実行が失敗する

Slide 25

Slide 25 text

トランザクショナルな仕組みを活用したい DBMSのトランザクション機能をいい感じに使って、他のテストケースと隔離されるテストケースが終わったらロールバック途中で失敗してもコミットされてないテストケース間でのDB操作がお互いに影響しない RSpec: use_transactional_fixtures Spring: @Transactional アノテーション

Slide 26

Slide 26 text

PrismaとJest環境の場合

Slide 27

Slide 27 text

3. 過去の自分の操作との競合

Slide 28

Slide 28 text

ここまでの対策で十分なのか？本当の敵は自分自身なんじゃないの？

Slide 29

Slide 29 text

ID name email(Unique) hogefuga test [email protected] 開発者A ローカルでちょっとした動作確認を行う Post /users データ作成

Slide 30

Slide 30 text

ID name email(Unique) hogefuga test [email protected] fugafuag test_user [email protected] テストケースでも同じようなレコードを作成していた（前処理）テストユーザー作成（test_user）テストユーザーログイン成功テストユーザーログアウト成功ユニーク制約でレコード作成失敗テストケースの実行も失敗

Slide 31

Slide 31 text

やめ（略）わた（略）つまりこう５分前に動作確認でDBレコードを作った自分自身

Slide 32

Slide 32 text

Ruby on Railsなどでは・・・ローカルでの開発時とテスト時で接続するDB を変更できる

Slide 33

Slide 33 text

とはいえ考えるべきことも・・・テスト実行前にテスト用DBにもDBマイグレーションを適用する必要があるテスト実行時に環境変数を読み込ませるなど、テスト用DBに接続しにいける準備が必要そもそも、そこまでする必要があるのか？発生してもDBリセットや辻褄合わせすればよい（許容できるか）

Slide 34

Slide 34 text

まとめ開発者に気持ちよくRDBが絡むテストを書いてもらうために考えていること

Slide 35

Slide 35 text

テスト作成ハードルを下げるために３つの競合を意識１他の開発者との競合個別のDBインスタンスやDockerコンテナ 2 テストケース間での競合トランザクショナルな仕組み 3 ローカルでの自分自身のオペレーションとの競合（テスト外で作ったデータなど）テストとローカル動作確認用のDBを分ける個人的に1と2は必須レベルで欲しい