皆さんVSCodeでセッションの共有をお願いしますね。実装していくかをライブデモします。REAME.mdに以下の文章を追記するテストおじさん。値が15ならばFizzBuzzを返すようにするTODOリスト何をテストすべきだろうか----着手する前に、必要になりそうなテストをリストに書き出しておこう。以下のコードを記述するテストおじさん。テストを実行してみましょう・・・はい、失敗。イエス、今やっていることはテストといいながら設計をしています。内容をそのまま転記してますからね。テストファーストいつテストを書くべきだろうか----それはテスト対象のコードを書く前だ。テスト駆動開発アサートファーストいつアサーションを書くべきだろうか----最初に書こうシステム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。機能はどこから書き始めるべきだろうか。コードが書き終わったらこのように動く、というテストを書くところからだ。テストはどこから書き始めるべきだろうか。それはテストの終わりにパスすべきアサーションを書くところからだ。クラスという意味です。Pythonは()の中に継承を記述するのね。ちなみにPythonは多重継承もサポートしているので複数のクラスを列挙できます。なんというかPythonのクラスの継承はカルチャーギャップがありました。注:テスト書いてないとt_wadaさんの前で言った人もテストおじさんもRubyがメインの人。ちなみにRubyだとこんな感じ。次は失敗するテストをパスするようにしないといけませんね。テストを実行してみましょう・・・はい、成功。0.000sOK仮実装を経て本実装へ失敗するテストを書いてから、最初に行う実装はどのようなものだろうか----ベタ書きの値を返そう。これで実装完了・・・とはいきませんね、ロジックを実装して本当にテストがパスするようにしましょう。テストを実行してみましょう・・・はい、成功。テストを追加してみましょうか。テストを実行してみましょう・・・はい、失敗。あー対応する処理がないからテストが失敗してますな。テストを実行してみましょう・・・はい、OK。2つ目のテストによってgenerateメソッドの一般化が実現できました。三角測量テストから最も慎重に一般化を引き出すやり方はどのようなものだろうか----2つ以上の例があるときだけ、一般化を行うようにしよう。内容もサクッと片付けちゃいましょう。テストを実行してみましょう・・・はい、オッケい!?。おっと、意図した結果と違いますね。デバッガで確認してみましょう。起動してステップ実行で条件分岐を確認するテストおじさん。15の場合は最初の判定で処理を抜けてますね、ここはこうかな。テストを再実行してみましょう・・・はい、OK。はい、これでTODOリストの内容を完了することができました。あー仕様にそれ以外では値を返すというのがあるのでテストに明記しておきましょう。その条件だと・・・ニヤリと笑うテストおじさん。実行・・・はい、仕様を書いた人が間違ってましたね。Rails)は自分で作ったけど一応自動テストは完備してますよ。解説しよう!テストおじさんはユーザー企業のぼっち社内プログラマなのだ。GitHubに公開されているプロダクトなんかはテストコードついてますけどね。テストコードを書くのは最初はしんどいけど後になるほど楽になります。スタティックメソッドのアノテーションなんですがスタティックメソッドはインスタンスメソッドとは違って・・・この後クラスの概念とかいろいろディスカッションする。・・・オブジェクトシコウムズカシイネ。これは少し複雑な感じがしますね、まずはテストコードを通して振る舞いを考えてましょう。引数に回数を取り戻り値に配列を返す振る舞いを設計しました。テストと言いながら設計をしているのです、そうテストではなく設計を!皮肉なことに、TDDはテスト技法ではない(Cunninghamの公案)。TDDは分析技法であり、設計技法であり、実際には開発のすべてのアクティビティを構造化する技法なのだ。・・・えーと、実装に移りますね。ここはセオリー通り仮実装。繰り返しの実行処理は・・・こんな感じかな。in一択だから・・・(しれっとrangeを使う)。テストして・・・よし、数字が連続して出力されてるな。これでいいかな・・・ありゃ。0から始まってるからなのね。カバレッジを満たすテストケースを追加してと。はい、これで仕様を満たすプログラムができました。設計ドキュメントを書いて開発・テストという流れとはずいぶん違いますね。いわゆるウォーターフォール型のアプローチだと最初にExcelとかでドキュメント書きますよね。解説しよう!テストおじさんはシステムエンジニアをやっていたのだ。ドキュメントがソフトウェアの変更と動機が取れていれば問題ないんですけどね。テストコードを見てください。これは仕様だから、こうしたほうがいいですね。vオプションをつけてテストを実行したら。これって実行できる設計ドキュメントみたいなものですよね。これまでの実装からもわかると思いますが従来のウォーターフォール型とは違う考え方がテスト駆動開発の根底にあります。私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。Programming)コードを変更する前に、失敗する自動テストを書くこと。含めてテスト駆動開発かなと思ってます。Design)システムの設計に毎日手を入れること。システムの設計は、その日のシステムのニーズにうまく合致させること。最適だと思われる設計が理解できなくなってきたら、少しずつだが着実に、自分の理解できる設計に戻していくこと。エクストリームプログラミングこの後、開発プロセスに関するディスカッションを行う。リファクタリング(名詞):外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。SERIES)リファクタリングする(動詞):一連のリファクタリングを適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。うーむ、なんというかコードを眺めていてこれはアレだなとかそんな感覚ですかね。実際にコードを見ましょう。コメントコメントを書いてはいけないなどと言うつもりはまったくありません。コメントは決して悪い臭いではなく、むしろいい香りなのです。ここでコメントについて言及しているのは、コメントが消臭剤として使われることがあるからです。コメントが非常に丁寧に書かれていたのは、実はわかりにくいコードを補うためだったということがよくあるのです。この場合は繰り返し処理を導出するための下書きコメントが冗長な消臭香をプンプン出してる感じですかね。コメントは配列を返すとあるのに実際は文字列を返すというコメントバグの原因になります。冗長なコメントは削除しましょう。テストを実行して変更がプログラムを壊してないか確認します。はい、冗長なコメント削除リファクタリング完了。