Shibuyarb20130515

ハイパーレガシーコード　　クリエイターだって

テストを捨てたい

13年5月19日日曜日

あんただれ


名前：瀬宮　新

職業：自宅警備員　ハイパーレガシーコード　　クリエイター


みなさん


こんばんは


家でコード書いてますか？


では


家でテストも書いてますか？



この前アプリ書いてたんですよ


本棚管理アプリ


一般公開したい

マルチユーザ対応


そうしたらコード汚いんですよ


どうにかしたい


リファクタしよう


コードをかえたので


テストも変更しなきゃ


テストがごちゃごちゃ


質の低いテストが大量


これはひどい


しかし量は多い


メッシュはバラバラ


カバレッジもよくない


どれを変更すれば・・・


正直　激おこ


どげんかせんと



過去の遺産


過去の成果物のレガシー化


そうだ


ひどいから全部捨てよう


実力も上がった


今ならもっとうまくやれる


変更部はコードをリファイン


テストコードもほぼ総入替


あれだけ書いたテストが無駄に


MOTTAINAI



ところで諸君


ユニットテストコードは滅ぼすべきだ


！？



そうじゃないんだ


@t_wada も言っている


実装が明白な場合はテストコードは書かなくてもよい


つまり実装が明白＝簡単な実装


簡単な実装＝テスト書かない複雑な実装＝テスト書く


・・・


お前が思うのならそうなんだろお前の中では(ry


そうじゃない


そもそも


簡単な実装＝テスト書かない複雑な実装＝テスト書く


この話の問題点


境界があいまい


簡単と複雑の境界って？


さらに


悪魔のささやき


「締め切りが近い」「最近徹夜続きで」


「別にこのコード、　　テスト書かなくても、

いいよね？」「だって簡単な実装だし」


そして、炎上へ



テストの目的って何か


不安をなくすこと


(開発者目線)


ではテストを書かなくても不安を感じない実装とは？


こんなの


# 円の面積を計算する

def compute_area_of_circle(半径) return 半径 * 半径 / 2end


あるいはこんなの


# 宅配便の荷物の高さを計算する

def 荷物の高さを計算する return 箱の高さend


このレベルまでは大丈夫

# 宅配便の荷物の３辺の合計を計算する

def 荷物の辺の合計を計算する return 高さ + 幅 + 奥行end


ここからは必要

def 荷物のサイズを判定する return compare_サイズ表(３辺の合計)end



ユーザのやりたいこと　・宅配便のサイズが知りたい　・料金が知りたい　・料金を払いたい

・・・


テストはミニユーザシナリオのレベルで行う


ユニットテストコードは書かない


そのためにメソッドは超シンプルに


テストを書く量が減る


開発早くなる


ウマー



ミニユーザシナリオのなにがおいしい？


説明タイム


ユーザの言葉でミニユーザシナリオ


その単位でミニユーザシナリオテスト


ミニユーザシナリオテスト

なにがおいしい？


コードの構造とドメインの構造の差異が小さい


機能の変更＝

ミニユーザシナリオの変更


ミニユーザシナリオにあわせて変更されるテストが明らか


変更負荷の軽減


テスト量も低下する


スローテストの回避



なにより


変更のコストが下がる変更の不安もなくなる


開発＝楽しい


楽しい開発で充実したハッカーライフを


Technology

Shibuyarb20130515