hirapi's blog

ちゃんとしたふりをする

「車窓からのTDD」をRubyで書き直してみる

やること

  • 「車窓からのTDD」(後述)を読みながら、出てくるjavaのコードをRubyで書き直してみる
  • TDDの雰囲気つかみつつ、Rubyのリハビリをする
    • 『レガシーコードからの脱却』を読んでTDDちゃんとやりたい気持ちが本格化してきた
    • ここ数ヶ月間対人の業務や別言語の仕事をしておりRubyほとんど書いていなかった
  • 簡単なユニットテストだけなので初minitestで
    seattlerb/minitest Rails テスティングガイド - Railsガイド

コード

TDDのステップをコミットに反映させたつもり

github.com

車窓からのTDD

http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf

  • 4ステップのサイクルを回す
    1. 💚 テストだけ書く → コンパイル/実行時エラー
    2. 🚗 テストに落ちるようにでたらめな値をハードコードをする
    3. 🚙 テストに通るように値を直す(fake)
    4. ♻️ テストに通る状態を保ったままリファクタリングする
  • トライアンギュレーション(三角測量・方法論的複眼)
    違う角度からの複数のテストを作り、全て通ることを確認していく
    1. 一度 🚙 にした後、仕様をより正確に表現するようにテストを追加する 💚 🚗
    2. テストに通るように実装を修正する 🚙 ♻️

スマホから見ると絵文字が違うっぽい

  • 🚗 は :red_car: で赤い車
  • 🚙 は :blue_car:青い車

考えたこと

  • こんなシンプルなコードに30近いステップがある……
    • 実務でほんとにやれるのか?
    • 最後のほう曰く几帳面に全部fakeしていかなくてもいいらしい(「明白実装」)
    • 実装に迷う部分はfakeで通して、そうでもないものはストレートに実装してもいいのかもしれない
  • 実装の詳細に迷って途中で中身をばこばこ書き直すことが多いので、とりあえずハードコードでテストを通しておくというのよさそう
    • 呼び出し元の視点でインタフェースを決められる、決めたインタフェースをぶれずに残し続けられる
  • 開発のタイムプレッシャーを打ち負かすくらいスムーズにTDDしたい
    • 涙無しには読めなかった『レガシーコードからの脱却』の生産性の話を信じる
    • このPDFにも最後に品質について同じことが触れられていた
    • 品質より納期を優先してしまうという開発、できればもうやりたくない
      どっちも取れる""力""が欲しい。息を吸うようにテスト書くようになりたい
  • テストケースが見慣れない感じだった
    • test_push_push_pop_top
    • テーマがやや低レイヤというかシンプルなデータ操作だったからかな
    • describe '#pop' の中に context '事前に1度pushされている場合' みたいなSpec式のほうが書き慣れてるかも
  • 思ってた以上にRuby忘れてた 😢