テスト駆動開発≒モデルの入出力を明確にして考える

プログラミング1でユニットテスト（doctest）自体は既にやり終えてましたが、復習も兼ねてもう一度。関数単位での動作確認をしやすくするため、使い方例示のため、といった振り返りをしつつ、今回はテスト駆動開発のお話も。

実際にはいくつかの要素を組み合わせて振り返ってるので、だいぶ時間が。

• まずテストを無視してシンプルな関数を書く。
• その関数を実行するコードを書いて動作確認。
• そのスクリプト1を別ファイル2からimportした時の動作確認。
• その理由を確認するためにbreakpoint指定してデバッグ実行。
• 特殊変数の確認と、これがimport時と直接実行時とで中身が変わっていることを確認。
• 元のスクリプト1を、__name__で動作変わるように修正。
• スクリプト1をimport時の動作と、直接実行した場合とでの動作の違い確認。
• doctest追加して、テスト実行。
• 関数を拡張して、2要素を返すように修正。戻り値がtupleになってることを確認。
• tupleに合わせてテストを修正。スペース有無含めてstr型での判定になっていることの確認。

ぐらいの内容で、ユニットテスト＋import＋関数戻り値を確認しつつ、新しいtuple型の説明までをまとめて実行。ユニットテストがあるとドキュメントを補足する例示にもなるよと。

それを踏まえて、同じ関数を「最初はコードを分からないものとし、最初にテストを書こう」ということでテスト駆動開発の話へ。

• 実現したい関数の入力と出力の組を1例考え、テストとして記述する。
• そのテストが通るような実装を書く。
• そのコードでは通らないような別のテストを書く。
• 以下繰り返すことで、少しずつ一般化していくことを考える。

みたいな演習。

テスト駆動開発がベストだとは思わないけど、モデルの入出力を明確にすることでそもそも何を実現したいのかを目に見える形にする、という点では間違いなく有用だよね。