LoginSignup
234
216

More than 5 years have passed since last update.

仕様変更に弱いからテストは書かない……?(´・ω・`)<仕様変更を想定するならテストを書いてくれ頼む

Last updated at Posted at 2018-08-01

テスト書けない人をディスったらバズりました。
スピード感重視なのでテストは書かない。テストはなぜ開発を遅くするか

気になる反応があったので別記事にまとめておきます。

「仕様変更に弱いからテストは書かない」

テストがあると頻繁な変更に弱い、と考える方が複数いらっしゃるようです。実際に、スタートアップの現場では、昨日の決定が今日と違うなんてことはザラにあります。

私の立場は「仕様変更が多いならテストを書いてくれ頼む」です。絶対に間違いなく一行の変更も加えず書いたコードを捨てることが決まっているのなら、テストは不要な可能性が高いです。しかし私の経験上は、プロトタイプであっても変更を加えたくなることは多々あります。その際にテストがないと困るだろう?というのが今回の主張です。

前提

  • フロント、特にGUIは私が無知なので対象としません。
  • 間違いなく書き捨てるコードは対象としません。少なくとも一週間くらい動かして多少の変更を加える予定のコードを想定しています。
  • 既存のレガシーコードは対象としません。新規で開発する場合を想定しています。
  • 最初から最後まで一人で開発するプログラムは対象としません。一人でやるなら好きにすれば良いと思います。
  • 頭の中でテストを完了できる方は対象としません。

今まで出会った、テストがなくて大変だった経験

個人的な経験です。

ありとあらゆる変更が、デプロイするまで結果がわからない

個別に開発環境容易するほどのリソースはないので、開発検証用の環境は一つだけで共有です。ローカルでの開発をエイヤで済ませた後、デプロイしてTracebackが出て(´・ω・`)となります。

もう一回ローカルで修正して、開発環境の順番待ちをしてからもう一回(´・ω・`)となる。

みたいなことを延々繰り返していきます。

テストがないって恐ろしい。

(´・ω・`)<入った瞬間に、ローカルでテストできるようにしようと言ったけど却下された

ちょっとした変更を加えて(デプロイしてから)動かすと、全く想定していなかったところでエラーが出てくる

よくわからないところで密に結合しており、一見なんの関係もなさそうな(というかあってはいけない)関数の変更で壊れます。
一般的にはテストファーストな実装をしているとIOが限られるため、こういう状態には強いのだが……

テストコードがあると、変更しやすくなります

上記は極端な例に思われるかもしれませんが、何も考えずにテストを導入しない環境はひどいことが起きます。
(´・ω・`)<それでも…テスト…いらない?

考えた末にテストやらないのならいいのですが、思考停止でテスト捨てると大概詰みます。

テストがあると変更に弱いと考えている人が勘違いしていそうなこと

  • 変更に強いテストと実装に技術力はいらないと考えている
  • 実装した人がいつまでもメンバーにいると思っている
  • 必ず全関数にテストを書かなければならないと思っていて、カバレッジ100%みたいな指標を持ち出す
  • 開発時のテストをそのまま実運用に使えると思っている。逆に、実運用に耐えるレベルの完全なテストを開発時に要求する

テストと技術力について

変更しやすいテストと実装を書くためには技術がいります。私が完璧かといえばそんなことありません。極めるのは遠い道のりです。

精進せずにコスト高いと言いはるのはいかがなものかと…。

テストファーストって設計レベルから絡む話なので、設計がうまくいかないと、コスト高いです。

実装した人いなくなったらテスト無しでどうするの?

実装した人がいなくなる事件は、何処の職場でもよくあります。この際にテストがないと詰みます。その関数で何がしたかったかわからないからです。
(´・ω・`)<テストのないコードを読むの大変

必ず全てにテストを書くかどうか

書かない、というか、書けない。たまに聞くのは「結果的に」カバレッジが80%~85%になるのが最善、だとか。

例えば私は「外部とのIO関連で、モックの山を築かないと実現できないテスト」は実装しないことが多いです。普通は外部パッケージを利用するので、テストはパッケージのコミュニティに任せましょう。

外部とのIOがビジネスロジックから切り離されていないなら、それはテストの問題ではなく設計の問題です。

開発時のテスト ≠ 最終的なテスト

開発時のテストを流用することもありますが、基本的に、開発中のテストがそのまま最終的な成果物になるという想定をおいてはいけません。ケースの抜けは間違いなくあります。逆に開発中に完璧なテストケースなんて作ろうものなら、間違いなく仕様変更のたびに開発が大幅に遅れます。

(´・ω・`)<なんで「テストを書け=完璧なテストを書け」みたいな極端な解釈になるんだ

まとめ

  • テストファーストは設計レベルで考えたほうが良い
  • 負担になるようなテストを開発初期に書かない
  • テストを書くことが負担なら、プログラマの技量とか、設計とかを見直した方が良い
  • テストを信奉しない

テスト書くの大変だと思ったら

記事追加しといた。

テストを書くかどうか議論するの不毛だから、どうやってテストを書きやすくするか議論しよう

234
216
17

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
234
216