私のテストコードの書き方

Transcript

1. 私のテストコードの書き方
2. 自己紹介 Atsushi Okui (@blue32a_jp) ソフトウェアエンジニア / Webアプリケーション エンジニア / PHPer 関心：設計、コード品質、リファクタリング、テス ト、モデリング
3. 【悩み】テストコードをどのように 書いていけばいいのか分からない😥
4. 自分がどのように書いているか 言語化してみる🤔
5. 前置き
6. 1. 自動テストへの期待
7. 自動テストに期待すること 自動テストに期待されることは様々ありますが、大雑把には下記の２つであると思われ ます。 • 品質保証 • 即時フィードバック
8. 自動テストに期待すること • 品質保証 • 即時フィードバック 👉
9. 品質保証としてはもの足りない ”「最も効果が高いのはテスト対象コードを書いた本人がテストコードを書くときである」 と述べましたが、これを裏返すと、開発者主導の自動テストからは第三者検証の観点 が抜け落ちてしまうということでもあります。書いた本人が気づいていない欠陥を、その 張本人が書いた自動テストがすべて検出してくれるわけではありません。品質を保証 するには実装者以外の目が必要で、それはピアレビュー（コードを別の人が詳細に評 価・検証するレビュー）やコードインスペクション（コードに不具合がないか人の目で確 認する作業 ） 、ペアプログラミング（1つのプログラムを2人で共同開発する手法）などで 適宜補わなければなりません。” 保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発 、その全体像 – 和田卓人(t-wada) https://gihyo.jp/article/2024/01/automated-test-and-tdd
10. 品質を保証するには実装者以外の目が必要 原則２：　プログラマは自分自身のプログラムをテストしてはなら ない． ソフトウェア・テストの技法 第２版 – p.15 https://www.kindaikagaku.co.jp/book_list/detail/9784764903296/
11. では、なぜ開発者自身が テストコードを書いてテストするのか🤔
12. 自動テストに期待すること • 品質保証 • 即時フィードバック 👉
13. 即時フィードバック テストを手動やっている多くのプロジェクトでは、スケジュールの後半にテスト工程が設 けられます。その場合、開発者が抱く「自分は何も壊さず、新しい機能を追加できている だろうか」という疑問や不安への答えが、数日～数週間、場合によって数カ月先まで得 ることができません。よって、より良い品質を求めるために試行錯誤できる回数が極端 に少なくなります。 テストが自動化されることによって、フィードバックをオンデマンドに得ることが可能になり ます。開発者は不安を感じた時にすぐテストを実行し、自分が進んでいる方向が正しい ことを確信したり、あるいは誤りに気づいてすぐに後戻りすることができるようになり、安 心して試行錯誤することができます。結果として、数カ月に１回のようなサイクルだった 試行錯誤が、数分に１回のようなサイクルになります。
14. テストには「品質保証」への期待もあるが、 設計・実装フェーズにおいては 「即時フィードバック」への期待が大きい
15. 2. テストはいつからできるか
16. 成果物が完成してから でないとテストは出来ない？
17. 例）２つの数値を足し算する test('２つの数値を足し算する ', () => { // Arrange // ??? // Act // ??? // Assert // ??? }); // todo
18. どのような結果が欲しい？ test('２つの数値を足し算する ', () => { // Arrange // ??? // Act // ??? // Assert expect(result).toBe(3); }); // todo 実行結果して２つの整数を足した数値が欲しい🤔
19. 結果を得るために、どのように実行する？ test('２つの数値を足し算する ', () => { // Arrange // ??? // Act const result = plus(a, b); // Assert expect(result).toBe(3); }); // todo ２つの数値を引数に取り、戻り値として足し算した結果を返す関数にしよう🤔
20. 実行するために必要なものは？ test('２つの数値を足し算する ', () => { // Arrange const a = 1; const b = 2; // Act const result = plus(a, b); // Assert expect(result).toBe(3); }); // todo 引数として渡すための２つの数値が必要だ🤔
21. 実装する test('２つの数値を足し算する ', () => { // Arrange const a = 1; const b = 2; // Act const result = plus(a, b); // Assert expect(result).toBe(3); }); function plus(a, b) { return a + b; } 👍
22. 成果物が完成していなくても テストを考えることはできる
23. どうやって（How）だけではなく 振る舞い・仕様（What）を一緒に考える
24. 本題
25. Q. どうやってテストコードを書いているか
26. A. プロダクトコードとテストコードを 一緒に育てていく
27. プログラミングするときの画面
28. プログラミングするときの画面 交互に少しずつ書いて、一緒に育てていく
29. 実践編 実際に書いている様子を記載したかったのですが諸般の事情で割愛します。󰢛 代わりとして、過去にプログラミングしている時の思考を記事にしているので、そちらをご 覧いただければ幸いです。（記事の内容はテスト駆動開発にフォーカスしたものですが、 だいたいこんな感じで書いています） 【実践 TDD Katas】 ローマ数字 https://qiita.com/blue32a/items/2084c9e5cff97980a1c7
30. プロダクトコードとテストコードを一緒に育てる 個人的な経験としても、レガシーコードに後からテストコードを追加するのはとても苦労し ます。これはテストのことが考えられていないため、テスト容易性が低い状態です。テス トコードを早いうちから書いていくことで、必然的にテスト用意性が備わることになりま す。 また「テストがしにくい」というのは「使いにくい」ということでもあります。「どうやって実現 するか（How）」ばかりに注目していると、完成した時に「動きはするが使いにくい」状態 になっていることがあります。こういった事態を防ぐため、常に使う側の視点を持っておく 必要があります。
31. 完成形が「分からない」からテストを書く プログラミングにおいてあまり効率的ではないと感じるのが「最短距離の完成形を考え てから一気に書く」という考え方です。分からない状態で考え込んでいても頭の中の成 果物はいつまでもボヤケたままで、時間だけが過ぎていきます。残念ながら、まだ道が ないところに最短距離はありません。このような手が動かない状態を回避するために、 テストを書くことで「何が求められているのか」を言語化し、それを「どのように実現する か」を試行錯誤していきます。
32. 正解はないし、一筆書きもできない https://x.com/t_wada/status/1892118836402405595
33. うまくいかない方法をたくさん見つける “I have not failed. I’ve just found 10,000 ways that won’t work.” 「私は失敗したわけではない。ただ、うまくいかない方法を1万通り見つけただけだ」 – Thomas Edison（トーマス・エジソン）
34. 【TIPS】必ずテストを先に書くべきか テストを先に書くテストファーストを採用するかどうかはスタイルだと思っています。実際 に先に書くこともあれば後になることもあります。重要なのは「テストが先か後か」よりも 「一緒に、少しずつ書いていく」ことの方だと思います。
35. まとめ • 開発者として、自動テストには「品質保証」よりも「即時フィードバック」への期待が 大きい • フィードバックをオンデマンドで得られることで、開発者は安心して試行錯誤すること ができる • 成果物が完成する前でもテストのことを考えることはできる • プロダクトコードとテストコードを一緒に育てていくことで、「テストしやすさ」「使いや すさ」も一緒に作っていく • 完成形が分からないからこそ、テストを書いて試行錯誤する
36. How do you like Testing?
37. 完