テストコード、書く派?書かない派?それぞれの言い分まとめ
skill

テストコード、書く派?書かない派?それぞれの言い分まとめ

2014.05.13

ent31_img01.jpg

システム開発の現場で、テストコードにどれだけのリソースを割くかは大きな問題。実際、まったく書かないという現場も多く、反対に、テストコードの重要性を強調する人もいます。
あなたはどっち派?
今回は、テストコードを書く派、書かない派、両者の意見をGeekroid(仮)調べでまとめました。迷っている人、決めかねている人は、参考にしてみてくださいね。
それではまず、書かない派の主張から…。(イワタテ

書かない派の主張1:テストコードを書く時間が確保できない。

「ただでさえ、システム開発の現場は時間に追われています。従来のテストコードを書かないというスケジューリングでもスタッフに無理を強いているのに、これ以上の作業時間をつくるのはちょっと難しいです」(33歳)

「テストコードを書くと、書かなければならないコードの量は倍か、それ以上にもなる。それだけの時間があったら、つぎのコード、つぎの案件にチャレンジしたい」(25歳)

書かない派の多くが感じているのは、テストコードに割くリソースを確保することの難しさのよう。確かに、テストコードを書くのには時間がかかりますよね。
一方、書く派の人たちは、「時間がかかる」という問題をどう考えているのでしょうか。

書く派の主張1:テストコードを書いた方が総合的な開発時間を短縮できる。

「テストコードを書くという行為だけ見れば、コストは増える。ただ、テストコードがあれば後からテストケースを追加したり、問題箇所を特定したりと、変化やトラブルに強い設計がしやすくなる。想定外の問題にスケジュールが乱される事態が減り、結果的に時短が達成できている」(27歳)

「テストに通っているという安心感がある。すでに書き終わった箇所に戻って、行ったり来たりするようなことがなくなって、目の前の作業に没頭できるようになったから、ムダな時間を省けているという実感がある。実際、開発終盤のデスマーチは、テストコードを書くようになってから避けられるようになりましたね」(26歳)

テストコードを書く利点は、小さな単位での品質を確かめながら先に進めることにあります。後から想定外の問題が発生する確率が下がれば、オンスケジュールの健康的な開発が実現できそうです。
ただ、書かない派からは、テストコードの有用性を実感できていないという意見も…。

書かない派の主張2:テストコードの効果を実感できない。

「以前はテストコードを書いていたけど、思ったほど効果を感じなかった。でも、書く時間は確実に増えた。だからとりあえず、書かないことに決めました」(30歳)

「費用対効果の問題。テストコードなしで成立してきた種類の案件にテストコードの文化を導入し、教育し、根付かせるには組織全体での大きな変化が必要。そこまでする効果を今のところは感じてはいない」(40歳)

「大人数でのプロジェクトならやった方が良いと思うけど、自分は1人か、多くても2~3人で仕事をしてる。少人数のチームであれば、本番がそのままテストと同じようなものだから、まぁ、書かないという選択で良いかと思っています」(36歳)

また、過去につくられたものを整備し続けるのは大変、という声も。

書かない派の主張3:テストコードの保守にさらにコストがかかる。

「テストコードもつくりっぱなしじゃなくて、保守しないといけない。長期的に工数を確保し続ける余裕がありません」(31歳)

「新規ならまだしも、既存のコードに手を入れる場合、カオス状態のコードをひとつひとつテストし直すことになる。放置されっぱなしの古いテストケースはそのまま放置するものだと思ってきたからそういうものをこれから自分もつくるのは不毛な気がする」(27歳)

「仕様変更の際、過去のテストコードが足かせとなって大胆な改善ができなかった経験がある。捨て去るのも勇気とは思うが、テストコードにも大きなリソースが割かれていることを考えると、やはり努力に見合わない気がしてならない」(34歳)

さらに書かない派の中には、書きたいけれど書き方がわからない、という層もあるようです。

書かない派の主張4:テストコードの書き方がわからない。

「何度かエンジニアとして転職したが、テストコードを書く現場を経験したことがなかった。だからテストコードを書く、といっても、どうしたら良いかわからない」(26歳)

「社内にテストを回す仕組みがない。テストコードを導入しよう、という声も上がっているのだが、そうするとスケジュールの切り方から、設計の仕組みまで大きく変わってくる。何から手をつければ良いのか、正直わからない」(26歳)

書かない派の中には、テストコードは「できたら良いな」という感覚はあるものの、ハードルが高い割には効果が実感できづらいもの、という認識があるのかもしれません。
それでは、書く派が想定している、テストコードを書くメリットはどんなものがあるでしょうか。

書く派の主張2:テストコードを書くことによって品質が高まった!

「一番の利点は、小さな単位でのテストを繰り返すことで、単体のパーツごとの品質が上がること。単体でテストできる環境をつくるので、ソースコードは間違いなく綺麗になります。結果的に、プロジェクト全体の品質も向上しました」(36歳)

「テストコードを使わないと一番最後に全体のテストを行って品質を担保するという考え方になる。テストコードを書けば、開発の途中段階で一定の品質を担保した状態から、さらに品質を向上させる時間を確保できることになる。最終的な仕上がりの差は小さくないと思いますね」(31歳)

また、大人数が関わるプロジェクトほど、テストコードの有用性が高まるという声も。

書く派の主張3:エンジニアひとりひとりが案件全体を見渡せるようになった!

「テストコードをみんなが書けば、全体の進捗や担当部分の役割が見渡しやすくなる。大規模案件であるほど、エンジニア間の意思の疎通にテストコードは有用だと思う」(30歳)

「テストコードを見れば、設計全体が理解しやすい。大きな案件はスタッフの入れ替えや引き継ぎが発生する場合が多々あるが、後から入った人も理解しやすいという意味で、テストコードは必須だと考えています」(29歳)

「環境依存度の強いコードは、仕様変更や引き継ぎの大きな障害。テストコードを書く段階で外部のDBを活用したり、オブジェクト同士の連携を意識した設計をすべき。環境依存度の強いコードって結局、すごく書けるエンジニアの個人プレーの産物であることが多いですが、チームとしてひとりのスーパースターに頼らない仕組みをつくるなら、テストコードは重要視しましょう」(30歳)

「テストコードを書くのは大変だ、というけど、最初は重要度の高いクラスだけテストすればそれでオッケー。テストありきではスピードが落ちるというのはまったく同感なので、必要な箇所とそうでない箇所を見極めながら、ゆっくりその文化を取り入れていけば良いと思います」(38歳)

経験の浅いエンジニアは、テストコードを書くことが勉強になった、といいます。

書く派の主張4:テストコードを書くことで自信になる、勉強になる!

「プロジェクトの最後に答え合わせをしていた時は、自分が書いているコードが本当に動作するのか不安を感じながら仕事をしていました。テストコードを書けば、不安なところはすぐに解消できる。成功体験を小さくともひとつずつ重ねていけるので自分のコードに自信が持てました」(24歳)

「転職の際、前職でテストコードをしっかり書いていた経験が評価されました。テストコードを書く習慣を導入している会社が増えていると聞いたので、自分はこれからもテストコードを書いて勉強をしていくつもりです」(25歳)

読者のみなさんは、書く派、書かない派、どちらの意見に共感しましたか?
もちろん、どちらが正解ということではありません。ただ、最近のオープンソース・ソフトウェアはそのほとんどに、テストコードが書かれているという状況もあります。これからは、テストコードを書く派がますます増えていくのかもしれませんね。

原稿:イワタテ
西東京市でコピーライター事務所をやってるイワタテです。
好きな言葉は「愛娘」。趣味は愛娘の写真撮影。
よく書くジャンルは、人材系、ビジネス系、IT系、ライフハック系、不動産系、おもしろ系……全部ですね。
Facebookの友達申請、お待ちしています。
https://www.facebook.com/iwatate1978

この記事はどうでしたか?

おすすめの記事

キャリアを考える

BACK TO TOP ∧

FOLLOW