Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

bun
November 21, 2023

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

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

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

bun

November 21, 2023
Tweet

More Decks by bun

Other Decks in Technology

Transcript

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

    View full-size slide

  2. みなさん、自動テストしてますか?
    (ご挨拶

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  11. 1. 他の開発者との競合

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  18. DBを個別に用意するだけでは
    (個人的に)ちょっと足りない

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  22. やめて!わたしのために(略)
    つまりこう

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  26. PrismaとJest環境の場合

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. やめ(略)わた(略)
    つまりこう
    5分前に動作確認でDBレコードを作った自分自身

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. テストを書く心理的ハードル
    を少しでも下げたい

    View full-size slide

  37. ご清聴ありがとうございました

    View full-size slide