テスト駆動開発)の本を読んでいます。レビューには,「読みづらい」とかいった話があるんですけれど,これはたしかに読みづらい。これは訳のせいというより,著者のナンセンスジョークや回りくどい比喩のせいなんだと思います。あたしゃ原書を読んでないんですけど,「こんなんどうやって訳すんだ」みたいな箇所があったんじゃないだろうか。どんなものなのかつかむことができると思います。キモは以下の5点を繰り返すことだったりします。小さなテストを追加する。すべてのテストを実行し失敗する。テストを実行し成功する。重複を取り除くために、リファクタリングを行う。本書の独特な波に乗るには,この点を実践的に踏まえている必要があるんじゃないかと思います。ないと,迷子になってしまう。何度も何度も繰り返しているんだろうけども。話をすると,あたしゃこゆ手法は,割とみんながやってることなんじゃないかと思っていました。ゴールとなる小さなテストケースを成功させていくことで,徐々に大きなモジュールにしていくアプローチです。本書ほど洗練されてはいないけれども,本体のプロジェクトを作ったら,テストプロジェクトも普通作るよね,と。ことで,本書の読みどころは,テストを成功させた後のリファクタリングにあるんだと思っていたりします。ま,それだったら,それ用の本を読めばいい話なんですけど。単体テストになるか」という話もあるんじゃないだろうか。しながら開発していくことといった認識だと思うわけで,多分それで間違っていないところもあるんだと思う。あたしの場合,単体というと「徹底的にやるもの」といった認識があるもんで,余裕があったらいつまででもテストしていたりします。んなもんで,普段から異常系のテスト量が非常に多かったりする。作った後は,小姑のようにいじめ抜くという......。テストはどちらかというとブラックボックステストに近い。言いすぎなら,グレーボックステストか。場合,ゼロ除算のテストケースを作るべきか,とかいった話になると,「そこまでせんでいい」ということになるんだと思います。普通,単体といったら限界値分析でゼロ除算になるケースをテストケースに入れるでしょ。正常系を作る上では不要なテストであっても,結合試験以降に起こりうる不具合に向けて,モジュールの堅牢性を高めておく(いぢめておく)ことは,普通するんだと思います。対応できるんだろうか。手順を説明しています。確実でインクリメンタルな開発をお望みの向きには,ぜひともお勧め。