未来の自分に渡すもの - テストが失敗したまま帰る話

フィードフォース ボドゲ部の id:kano-e です。
ゲムマ楽しかったですねー！！！
遊びたいボードゲームが多すぎて大変です。みんな遊んで！
（会社の Advent Calendar でボドゲ部のこと書いたので、そちらも是非ご覧ください）

さて、自分は時々退勤前に「テストが通らない状態」で帰ることがあります。
ずいぶん前に何かで「キリの悪い状態で帰る」とか「テストを落として帰る」みたいなことを聞いてから（この話何で聞いたんだっけ？）、なんとなく意識してることです。

特に連休前や飲み会を挟む時にはとても有効な手段です。

1. 最初は何も考えずに手を動かせば良い状態にしておく
2. 単純な修正をやっているうちに、徐々に次に何をやれば良いのかが思い出せる

という状態に、次の日の自分を誘導できればベターですね。

describe '#execute' do
  it 'update status to active' do
    expect(subject).to change { model.reload.status }.to(:active)
  end
end

というテストだけ書いて実装してない状態で飲み会に参加して帰りに飲み足りなくて氷結を2本買って帰ってすっかり良い気分で眠って起きて全部忘れて出社なんかするわけです。
その状態でも、とりあえずテストを走らせれば「こいつの status を active にすれば良いのか」ということがわかる。
なので、とりあえずテストを通す最低限の実装をする。
その間に頭が働き始めて「active はどこからくるものだったのか」みたいなことなんかを思い出してくる。
という感じです。

TDD のサイクルなので、単純に手を動かし始められ、すぐにコードを書き始められ、そしてそのまま集中状態に入っていけるのが良いですね。

あるいはもっと単純に、コメントだけ残しておくこともあります。

it { expect('この時点であれが nil になっているケースがあることに気づいたけど、そういう場合どうなるのが良いんだ？').to be false }

「良いんだ？」ってテストでもなんでもないですね。
まあ PR にする時には履歴にも現れないテストなので、許してください。

こういうのも、次に見た時には存外落ち着いて「これが nil の場合の context 書いて、その場合は例外が妥当かなー」とテスト書けるようになっていたりするものです。
テストさえ書けてしまえば、あとはその通りに実装するだけですね。
そのまま良い流れに乗ることができます。

さて、 TDD については、みなさん『テスト駆動開発』を読みましょう。良い本ですよ。

テスト駆動開発

『テスト駆動開発』についての記事は他にもありますので、よろしければこちらもぜひ。

developer.feedforce.jp

developer.feedforce.jp