今更テスト駆動開発がバズワードと言われるのも、結構時間が経ってるから違う気もするけど。
バズワードとして受け取られるテスト駆動開発
自動テストって大事なんだけど、バズワードと感じてしまうのは、大事さが独り歩きして、踏み絵やチキンレースみたいになっている感じがするとき。
「えwwwwwww テスト書いてないの？ 開発者として終わってんじゃん。うちのシステムはめっちゃCI動いてるけどね」
「最近テスト駆動開発はじめたけど、マジで良いわ。単体テストからめっちゃテスト書いてるから、ちゃんとしてる俺マジエンジニア」
こういうこと感じのニュアンスでマウントをかけられると、イラッとする。そう言ってるあなた、どれほど仕事でテスト書いてるんですか、って思うし、テスト書く文化が形骸化していきそうな雰囲気を感じる。
なんでテストを書かない時があるか
書けばいいじゃん、その方がエンジニアっぽいしって言うだろうけど、書きたくないときもある。
だって時間がかかるんですもの。
ちょっとしたテストでも、既存テストの拡張とかじゃない場合、1,2時間かかる。
（実はテスト慣れしていないっていうのが一番大きいんだけど、書いていない人が重い腰を上げるときは時間かかる）
コード書いたり修正するのが30分とかしかかかってない小さい修正なのにそんなかかるのは割に合わない感じがしてしまう。
特に機能拡張や修正したときに、既存コードにテストがなかったら、介護感があり、なお嫌だ。
自分の修正が30分で終わったのに、なんで既存コードのために4時間テストを仕込まないといけないのっていう。
特にそんな場面で、「単体テストから積み重ねて」とか言われると「うっせ！」って思ってしまう
自動テストは誰のため？
こんな愚痴を述べておきながら、やはりテストは大切だと思う。
自動テストが書かれるといろんなメリットがある
- テストで保証するものは仕様(spec)であり、変なコードを書いてもテストがそれを弾いてくれるため、テストが書かれたコードでユーザがバグを踏まないで済む
- 1回書けば、その仕様は、特にケアしなくてもそれ以降テストがその仕様を守ってくれる
- 将来修正されなさそうな1回限りのコードでも、誰かが手動で動作確認するコストを、テストコードを書くことで賄ってくれる
テストによって<開発者>の<心理的安全性>が保証されるため、開発者にメリットという言説もあり、もっともだが、
やはり、テストの根底にあるのは製品を守る、品質確保の意味が大きいと思う。
テストはユーザのためになるし、
もっと生々しく言えば、バグったときに痛手を被ったり、そうならないように動作確認を求められるPOにとって自動テストは大事と言える。
動作確認は本業以外の時間を結構持っていくし、もちろんケースが膨大なため漏れもあるからだ
（テストの時間が取れない場合、意思決定者であるPOのためであるっていうことを言うと、意外と納得されるかも笑）
仕様メインにしてしまうと、アイスクリームコーン問題が取りざたされる可能性はあるが、それでも製品の品質・仕様を守るという側面を強調したい
絶対自動テストを書いた方がいい場合
上記に書いたとおり、テストは品質を守るためのものだと私は考えている。
ただ、コストがかかる以上、無尽蔵に時間をかけられない。
特に既存システムが動いており、それらにテストが書かれていない場合はなおさらだし
全てのテストを手厚く守れるかというとそれもコストがかかるから難しい。
では、どこのテストは書かなければいけなく、特に手厚くしなければならないのか。
それは、バグったときの影響がやばいところである。
システムが止まる、売上に影響がある、信頼を失う。そういった影響が大きいところは是が非でもテストを書きたい。
その影響に比べたらテストを書くコストなんて安いもの、と言えるところは是非テストを書いたほうがいいだろう
（なんだったら、その点についてビジネスオーナーと話しても面白いかもしれない。ビジネスオーナーを守る堅固な城壁となるため、その人からの評価も上がるかもしれない）
テストを書くということは、その仕様を守っていきたい、という開発チーム、ひいては事業部、会社の意思表示であり、
大事な部分をコストをかけてまで守るという営みである。
そういった部分はぜひともコストをかける意思決定をしたい。
テストを書かない場合
逆に言えば、バグっても「テヘ」で済むようなところには、私はテストを書かない可能性が高い笑。
極端な話、文言修正時に、そのテストを書くわけない。
『アジャイルソフトウェア開発宣言』に「完全なドキュメントよりも、動くソフトウェア」とあるが、神経症的にテストを課すのは、現代版の「完全なドキュメント」に近く、コストが上回ってしまう気がする。
SIerの誰も読まない膨大なドキュメントの日々のメンテみたいな感じで。
この場合は手動動作確認で済ましちゃうかな
もう一つ、テストを書くかどうかを考えるときの観点は、手動動作確認のコスト。
「テスト書くの面倒じゃん」は言いやすいが、あまり表面化しないが、手動動作確認も意外と時間かかる。
- A. 複雑な条件を自分で準備しなければならない
- B. 1回の試行が一瞬で終わらない。5回やると疲労感感じるくらい(=0.5~1h)かかる
- C. 影響箇所が1箇所より多いと、試行回数が必要
- D. 重要な機能だと、間違ってはいけない、とプレッシャーがかかる
- E. 失敗すると、複数セット同じことを試す必要がある（A~Cの困難が複数セットのしかかる）
といったような、時間が膨れ上がる要因がある。
自動テストも時間かかるけど、手動動作確認してたら、思ったより時間がかかったという経験がある人も多いのではないだろうか。
なので私は
- 動作確認の準備がほぼかからず（A）
- 影響箇所が1箇所で(B,C)
- バグってもテヘで済む(D)
- 変更・追加した挙動がコードから自明にわかり（例: 文言修正）、失敗可能性がほぼない(E)
場合にはテスト書かないけれども、
それ以外の場合はテストを書こうかな、と思う。
まとめ
テスト駆動開発はまだバズワード感が伴う概念であるが、
「テスト書かないと誰かになじられる」
「テスト駆動開発の名称通り、開発前にテストを書かねばならない」
といった強迫観念にとらわれるよりも、
MUSTでテストを書かなければならない場所にコストをかけていく姿勢をまずはやっていきたい
（慣れてきたら開発前にテスト書く、文字通りのテスト駆動もやってみようかな）