rch850 の上澄み

技術的な話題とか、雑談とか。タイトルを上澄みに変えました @ 2020/09/02

TDD Boot Camp 北陸に行ってきたんですよ

被らないようにタイトル考えるのも大変ですね。TDD Boot Camp 北陸に行ってまいりました。

会場

三本柱

  • バージョン管理
  • テスティング
  • 自動化

三種の神器」だと、どれかが欠けても大丈夫そう。深刻さが足りない。

書籍紹介ラッシュ

だいたい有名どころですが、あらためて。

Emergent Design: The Evolutionary Nature of Professional Software Development (Net Objectives Lean-Agile Series)
創発的設計を為すピラミッド。ベースにあるのはコードの質。

Emergent Design とは

達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化 (Ascii software engineering series)
黒より白!アスキーから出ている方に上記の三本柱について書かれています

以下三冊は、現場で戦うあなたへ

レガシーコード改善ガイド (Object Oriented SELECTION)
テスト不在のコードと戦うための良き友
データベース・リファクタリング
本番データがすでに入ってしまっているデータベースと戦うための(ry
xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
テストケースが増えてきて、テストのリファクタリングが必要となったときの(ry

ペアプロのデモ - FizzBuzz

id:t-wada を t、id:katzchang を k と略しています。

  • t「3の倍数を渡すとFizzと返す」
  • k「3がエラーになってる」
  • t「漢数字にしよう」
  • k「クラス名何にしよう……」
  • t「それじゃだめ。まずは assertEquals を書く。assertEquals("Fizz", actual)」
  • k「じゃぁ、assertEquals("Fizz", fizzbuzz(3)) で」
  • t「fizzbuzz メソッドを Eclipse で自動生成」
  • k「もっとも簡単なコードでテストを通す。 return "Fizz";」
  • t「なんでこんなことをするのかというと、テストのテスト。仮実装をバカにしてはいけない。テストを足していいのは green のときだけ」
  • k「次のテストメソッド名は、"_1を返すと1と返す"」
  • t「あ、アンスコつけるんだ」
  • k「わりとよくやります」
  • t「はい red になった。これが三角測量。ここから仮実装するか、一気に解くかは個人個人のスキル」
  • k「じゃぁ一発で実装。よし、green」
  • t「まずテストの名前を決める。assertを書く。メソッド名についてはもめてください。次はテストを書く。仮実装かどうかはペアに任せる。仮実装だったばあい、それを打ち破るテストを書く。」

Python で TDD ペアプロ

ペアプロのお時間には、Python チームにまぎれてました。unittest モジュールと、doctest でのテスト。プロダクションコードのコメントとして書きつつも、しっかりとテストとして機能する doctest は素敵ですね。Java でもアノテーション駆使してこんなこと……はさすがに難しいか。そもそもバイナリサイズが膨れてしまいそうで微妙です。

ペアプロなので、書きながら「この関数の仕様はどうする?」という話になるわけですが、例外処理の扱いをどうするかがだいぶチームによって異なりました。結果的に @hikaruworld チームでは、引数に想定外の型が入ってきたら明示的に raise ValueError、@yuuitiro チームでは、そういった型チェックはしない、という方向性になっていました。

せっかく LL らしく、本質的な部分を数行で書けてるのに、型チェックの部分のコードが長くてかっこわるいーという話を @hikaruworld としていたところ、@cafistar から「それデコレータできれいにかけるよ」というアドバイスをもらい、きれいに書き直すことができました。こんな感じで夜は更けていく……

対レガシーコード

2日目は @wtnabe のレガシーコードと戦いました。言語は Ruby だったんですが、チーム内の過半数Ruby よくわからないという状況。それでも、徐々に慣れつつ、最終的には目的としていた仕様変更を達成できました。RSpec がどういう感じかなんとなくつかめたかも。it "hoge" do ... end の中で、オブジェクトが拡張されて should などが追加されるという仕組みにおどろきました。

つまるところ

  • マクロなテストからミクロなテストへと絞り込んでいく
  • もっとちゃんとレガシーコード本読もう
  • エディタ、キー配列の宗教戦争は偏在する
  • 未知のエディタ、言語でも、その道の先輩とペアプロすればなんとかなる
  • ビーバーは加賀名産
  • JOJO勉強会により、黄金の回転(Red, Green, Refactoring)への理解が深まる

写真は flickr にあります。