変更につよいユニットテストの書き方.pdf

変更につよいユニットテストの考え方鈴木まー PHP勉強会

自己紹介 @suzuki_mar

鈴木まー(suzuki_mar) RubyでDDDやモジュラーモノリスなどのソフトウェアアーキテクチャの導入、定着をしている PHP/Laravelで仕事をできるように転職活動中＆スキルアップ中直近の仕事最近していること
オブジェクト指向カンファレンスの動画を30ぽんぐらい公開した LTやブログなどで設計などをアウトプット PHP Sessionless Conferenceのコアスタッフになったばかりコミュニティ活動 @suzuki_mar プログラマー以外にプロレス団体のプロモーター的な活動をボランティでしている名古屋で3000人の会場を埋めることを考えている

登壇をする前に @suzuki_mar 今回がはじめての20分の登壇なので不手際があるかもしれないですけどよろしくお願いします

話すこと @suzuki_mar

ユニットテストの目的を理解し、プロダクションコードとテストコードの依存関係を作らずに、プログラミングの振る舞いに対して各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

話さないこと @suzuki_mar ユニットテストの書き方などユニットテストを書いてあることを前提としています

ユニットテストの本や資料はたくさんあるのでそちらをみてください @suzuki_mar t-wadaさんの TDDBC Sendaの動画 https://www.youtube.com/watch?v=r0o54M0J850

前提知識ユースケースクラス @suzuki_mar

自分の設計ではユースケースクラスが肝になっているので今回もそれを使って説明をしますユースケースクラスとはAPIのリクエスト、レスポンス以外のプログラムが何をするのかを書くクラス前提知識ユーケースクラス @suzuki_mar

ユースケースクラスを ADRパターンのACTIONクラスという認識でもOK 前提知識ユーケースクラス @suzuki_mar

前提知識ユーケースクラス @suzuki_mar Action リクエストを受け取り、ドメインの処理結果をレスポンダに渡す Domain 必要な処理を行い結果を返すビジネスロジックはここに含まれる Responder ドメインの処理結果を受け取り、必要な準備を行いレスポンスを返す

前提知識ユーケースクラス @suzuki_mar 次のテキストをもとに解説していきます

ユニットテストの目的を理解し、プロダクションコードとテストコードの依存関係を作らずに、プログラムの振る舞いに対して各レイヤーの粒度にあった必要十分なテストを書いていく

ユニットテストの目的 @suzuki_mar

よくある勘違いユニットテストはプログラミングの品質を保証していてバグがないようにテストをしているするものユニットテストの目的 @suzuki_mar

ユニットテストは、開発者が想定している通りにプログラムが振る舞うことをテストを書きながら検証し、保証するためのものユニットテストの目的 @suzuki_mar

開発者が仕様を誤解していたり仕様自体に誤りがある場合はバグが発生するユニットテストの目的 @suzuki_mar

ユニットテストではバグが発生する可能性があるのになんで時間をかけてテストコードを書く必要があるのかユニットテストの目的 @suzuki_mar

ユニットテストは開発者用のテストとして想定外の場所でバグが発生していないことを保証したりこのコードはこの通りに動くという前提でプログラミングをすることができるユニットテストの目的 @suzuki_mar 開発者のための安心ガード

E2Eテストや受け入れテストユニットテストの目的 @suzuki_mar 品質保証テストユニットテストｔ

E2Eテストや受け入れテストユニットテストの目的 @suzuki_mar 品質保証テストユニットテストデベロッパーテストｔ想定通りに動作しているかを素早く確認し、開発をサポート

ユニットテストの目的 @suzuki_mar ユニットテストは開発者をサポートするためのテストメンテナンスしやすいようにテストを書いていくことが大切ｔ

ユニットテストの目的 @suzuki_mar ユニットテストがメンテナンスしづらいものだったら開発者の足かせになってしまう逆にｔ

ユニットテストの目的 @suzuki_mar メンテンナンスしやすいユニットテストｔ

ユニットテストの目的 @suzuki_mar メンテンナンスしやすいユニットテストｔプロダクションコードが変更してもテストコードがこわれない

ユニットテストの目的 @suzuki_mar メンテンナンスしやすいユニットテストｔプロダクションコードが変更してもテストコードがこわれない開発者が実装した振る舞いをおこなうことが保証されている最小限のテストコード

プロダクションコードとテストコードで依存関係をつくらない @suzuki_mar

プロダクションコードとテストコードの依存関係を作らずに

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar 依存関係があるとはプロダクションコードの定義をテストコードでも定義を参照してしまうためプロダクションコードの変更時テストコードも壊れるｔ

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar Userクラスに新しいユーザーを取得するメソッド User::fetchNewestが実装されているので以下のテストコードを書いているｔどういうことか $this->assertNotNull(User::fetchNewest());

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar 仕様変更が発生して新しいユーザーを取得するのではなくて認証している新しいユーザーを取得するということになり次のメソッド名になったｔ User::fetchAuthenticatedNewest())

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar さきほどのテストコードを次のように変更しないとけいないｔ $this->assertNotNull(User::fetchNewest()); $this->assertNotNull(User::fetchAuthenticatedNewest())

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar わかりやすい例がprivate Method に対してテストコードをかいてしまうため依存関係が生まれる private MethodはPublic Method よりも変更をする頻度がおおいためテストコードを
変更する必要になってしまうｔ

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar 一つのメソッドだったら問題ないがこれが、 100個メソッドに対してテストを書いていたら少しずつだけど塵が積もればとなり負担になっていくｔ

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar プロダクションコードとテストコードが依存しているとCIを実行すると度々テストコードが Error: Call to undefined method
などのようなエラーをおこしてしまう

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar その結果虚無状態になりユニットテストを書きたくなくなる

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar どのようなテストを書いていくか

プロダクションコートとテストコードの依存関係をつくらない @suzuki_mar プログラムの振る舞いに対してテストを書いていくどのようなテストを書いていくか

プログラムの振る舞いに対して

プログラミングの振る舞い @suzuki_mar

プログラムの振る舞いは、定義された仕様に従って動作することを指す仕様の重要な部分はユースケースとして記述されるユースケース記述は、各ユースケースの詳細な流れや条件を説明しているプログラミングの振る舞い @suzuki_mar

ユースケース記述は以下の項目が存在するアクター誰が何をするか前提条件ユースケースを実行できるための条件メインフロー　ユースケースとして何をしていくか代替フローメインフローが実行できない場合にどうするか事後条件
ユースケースの実行後に達成される結果や状態プログラミングの振る舞い @suzuki_mar

ユースケース記述の例 ECサイトの注文プログラミングの振る舞い @suzuki_mar

アクタ9 主アクター：購入0 副アクター：システム、CS（カスタマーサポート）前提条件・購入者のIDが正しいこと事後条件・商品が購入されているプログラミングの振る舞い
@suzuki_mar

メインフロー支払い情報を入力するまA V1 システムは購入者がブラックリストに登録されていないことを確認すx %1 購入者がブラックリストに登録されている場合e 1 システムは購入者に購入できない旨を通知すx 1 ユースケースを終了すx
1 購入者が住所を入力すx 1 システムは外部のアドレスチェックAPIに入力された住所が正しいことを問い合わせx %1 住所が間違っている場! 1 システムは購入者に住所が間違っていることを通知すx 1 購入者に正しい住所の再入力を促すプログラミングの振る舞い @suzuki_mar

メインフロー購入処理を終了するま` vb 購入者が支払い方法を選択する（クレジットカード、PayPay、モバイル決済 "b システムは購入者の支払い能力を確認す 'b 購入者の支払情報が間違っている場 &b システムは購入者に支払い情報が間違っていることを通知す
&&b 購入者に正しい支払い情報の再入力を促p &&&b 支払い能力を確認できない場合はユースケースを終了す Àb 購入者が商品を購入するプログラミングの振る舞い @suzuki_mar

サンプルコードプログラミングの振る舞い @suzuki_mar

正常処理購入に成功したことを確認している

ユースケースの実行Ⅱ 失敗したことのテストブラックリストに登録されている場合はカスタム例外クラスが発生している振る舞いをしているはずプロダクションコードとテストコードが依存している例メッセージを変更するたびにテストコードを変更する必要がある他の失敗したことのテストは同様に書いていく

先ほどのようにテストコードを書いていけば、実装者はユースケースがプログラムが想定しているとおりに振る舞うと自信を持って言えるプログラミングの振る舞い @suzuki_mar

BlackList::checkなどは本当に自信をもっていると動いていると言えるかプログラミングの振る舞い @suzuki_mar

ユーザーをブラックリストに入っていると扱う条件は複雑プログラミングの振る舞い @suzuki_mar 繰り返しの支払い失敗不正な返金要求やチャージバックの頻発虚偽の「商品未着」申告不自然な頻度での返品や交換複数アカウントの不正利用

ただ、これをユースケースのテストを書くとテストが複雑になってしまうそのため、BlackListのユニットテストを書いたほうがいいプログラミングの振る舞い @suzuki_mar

Addressの確認はただ、外部APIにアクセスするだけのシンプルな場合 AddressCheckerのテストを書かないでもユースケースのテストだけで動いていると自信を持っても良いプログラミングの振る舞い @suzuki_mar

実装者が複雑だと思うものに対してだけクラスに対してのテストコードを書いていくプログラミングの振る舞い @suzuki_mar

各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

各レイヤーの粒度にあった必要十分なテストを書いていく

ユースケースクラスがある場合の各レイヤー Featureテスト　 UseCaseテスト個別のクラスのテスト各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

ユースケースの実行が正しく振る舞っていると過程して APIへのリクエストパラメーターのバリデーション等が正しく実行されてることユースケースが実行されているレスポンスで返すが正しいレスポンスコードなどが問題ないこと Featureテスト APIが正しく振る舞っていることの確認　各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

ステータスコードが正しいことのテスト

UseCaseが正しく実行されていることのテスト UseCaseが正しく振る舞っていると ordersにデータが作成されるという前提に立てる UseCaseが正しく振る舞っていることはUseCaseのテストで保証されているこれだとUseCaseクラスのクラス名やメソッド名が変わってもテストコードを書き直す必要がない

ユースケース記述どおりに振る舞っているかをテストするさきほど説明した以下のようなコードを書く UseCaseテスト　

実装者が自信を持ててコードを書いていないものに対してだけテストを書くメソッド名などはプロダクションコードと依存してもよいクラスに対するテスト　一般的に簡単だと思えることでも実装者が難しいと思う場合はクラスに対するテストコードを書く

クラスに対するテスト　

BlackList::Checkは仕様が複雑だけどクラスに対してテストコードをかいているため実装者の実装通りにクラスが振る舞うという前提にたてるそのため、BlackListに関することのユースケースのテストは簡単なものでいい

図解 Featureテスト (送信されたパラメーターが正しいかどなど) UseCaseテスト (ユースケース記述どおりにテストがじっこうさること) Featureテスト (UseCaseが実行されているか、ステータスコードが正しいか) 複雑な個別のクラスのテスト

このようにテストコードを作成すると必要十分なテストを書くことができる各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

テストコードが少ないほどユニットテストのメンテナンスするものが少なくなる結果、変更に強いユニットテストになる各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

まとめ @suzuki_mar

ユニットテストの目的ユニットテストは開発者をサポートするためのテストメンテナンスしやすいようにテストを書いていくことが大切各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

プロダクションコードとテストコードの依存関係各レイヤーの粒度にあった必要十分なテストを書いていく依存しているとCIを実行すると度々テストコードが Error: Call to undefined method
などのようなエラーをおこしてしまう @suzuki_mar

プログラムの振る舞い各レイヤーの粒度にあった必要十分なテストを書いていく定義された仕様に従って動作することを指す仕様の重要な部分はユースケースとして記述されるユースケース記述は、各ユースケースの詳細な流れや条件を説明している @suzuki_mar

各レイヤーの粒度にあった各レイヤーの粒度にあった必要十分なテストを書いていく Featureテスト (送信されたパラメーターが正しいかどなど) UseCaseテスト (ユースケース記述どおりにテストが実行するか) Featureテスト (UseCaseが実行されているか、ステータスコードが正しいか)
複雑な個別のクラスのテスト

ユニットテストの目的を理解し、プロダクションコードとテストコードの依存関係を作らずにプログラムの振る舞いに対して各レイヤーの粒度にあった必要十分なテストを書いていく @suzuki_mar

新しい仕様が加わったらどうテストを書くか @suzuki_mar

みなさんも一緒に考えてください @suzuki_mar 新しい仕様が加わったらどうテストを書くか

新しい仕様が加わったらどうテストを書くか @suzuki_mar 在庫チェック RDBで在庫を管理しています在庫が存在しない場合はエラーステータスコードを返す

新しい仕様が加わったらどうテストを書くか @suzuki_mar 次のテストを書く

新しい仕様が加わったらどうテストを書くか @suzuki_mar 在庫がない場合にユースケーステストでエラーが発生することをテストする次のテストを書く

在庫チェックはDBにデータがあればいいのでユースケースだけのテストで十分新しい仕様が加わったらどうテストを書くか @suzuki_mar

新しい仕様が加わったらどうテストを書くか @suzuki_mar 在庫がないエラーがユースケースで発生した場合に APIのレスポンスとしてエラーステータスコードを返していることをテストする次のテストを書く在庫がない場合にユースケーステストでエラーが発生することをテストする

在庫チェックでエラーが発生した場合は新しくエラーステータスを返す必要があるのでFeatureTestにそれを追加する新しい仕様が加わったらどうテストを書くか @suzuki_mar

新しい仕様が加わったらどうテストを書くか @suzuki_mar ポイント付与ルール通常のポイント付与会員のステータスに応じた追加ポイント商品の種類によるポイント付与率の変動特定期間中の特別なポイント付与ルール顧客の最初の購入に対する特別ボーナス高額購入に対する追加ポイント

ポイント付与ルールは複雑なので何ポイントを付与するクラスを作成してそのクラスのためのテストを書く新しい仕様が加わったらどうテストを書くか @suzuki_mar

ユースケースのテストにポイントが付与されていることのテストをするクラスに対するテストを書いているため何かしらのポイントが付与されていることを確認するだけでいい新しい仕様が加わったらどうテストを書くか @suzuki_mar

新しい仕様が加わったらどうテストを書くか @suzuki_mar

ポイント付与されても APIの振る舞いには変化がないので FeatureTestにはテストを追加しない新しい仕様が加わったらどうテストを書くか @suzuki_mar

参考文献 @suzuki_mar

参考文献 @suzuki_mar 単体テストや統合テストの基本から設計の重要性まで幅広く解説し、実践的なアプローチを提供しています。 Mocking戦略やTDDの設計行為としての役割にも触れており、テストコードの問題点にも洞察が得られます。引用
https://www.amazon.co.jp/product-reviews/4839981728/ref=acr_dpx_hist_5? ie=UTF8&filterByStar=five_star&reviewerType=all_reviews#reviews-filter-bar

参考文献 @suzuki_mar ユースケースに基づく設計手法を丁寧に解説し、設計から実装までの具体的な流れを学べます。複雑な要件整理やモデリングの実践例も豊富に含まれ、理論だけでなく実践的なスキルを身につけたい開発者にとって非常に役立つ一冊です。引用 https://www.amazon.co.jp/product-reviews/4839981728/ref=acr_dpx_hist_5?
ie=UTF8&filterByStar=five_star&reviewerType=all_reviews#reviews-filter-bar

終わり

変更につよいユニットテストの書き方.pdf

変更につよいユニットテストの書き方.pdf

More Decks by suzuki masayuki

Featured

Transcript