Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
24
Help us understand the problem. What is going on with this article?
@ham0215

[2021年]継続的に開発するプロダクトならテストコードを書こう

皆さん!テストコード書いてますかーーー??

TDD(テスト駆動開発)やCI(継続的インテグレーション)という言葉が広く知られるようになって数年経ちますが、2021年の現在でもテストコードを書いていない現場をちらほら見かけます。

テスドコードを書いてテストを自動化している私の感覚では、継続的に開発するプロダクトにおいてテストコードを書いていないのはありえないです!!

よく聞く言い訳として、テストを書く工数がないということが言われます。
ただ、1度でもテストを書いていた経験がある方だとわかると思いますが、テストを書いていない場合は既存コードに手を入れるときに確実に余計に工数がかかります。
テストは未来への投資です。そしてその投資は次に手を入れるタイミングでもう返ってきます。速攻で返ってくるのでやらない手はないです。

※最初に「継続的に開発するプロダクト」と書いた通り、今後絶対に手を入れないようなコードであれば書く必要な無いかもしれません。

そんなこと言ったってうちの現場はテストコードを書かない方針なんだ

既存コードにテストがない場合、改修したり新規コードを追加した時にもテストを入れずに終わらせることが多いと思います。
私も以前はそうでした。既存コードにないことを言い訳にテストコードを書かずにいました。その分、頑張って手動でテストしていました。

そういう環境にいるとテストを書かないことが普通になってしましますが、可能であれば自分の担当領域だけでもテストを書くようにしてみましょう。
もしチームをリードするポジションの方であれば自分から初めてテストコードを書く文化を徐々に広げていければ素敵だと思います。

ただ、テストがない環境の場合、テストを書くことをよく思わない人がいるかもしれません。(なんでテスト書いてるんだ!工数がもったいない!!)
そう言われてしまい、かつ、立場上どうしようもない場合は諦めることをおすすめします。
(人や文化を変えるより、職場を変えるほうが数倍簡単です)

とにかく始めてみよう

テストを書いたことがない方はとにかく始めてみましょう。
様々な記事だけ読んでいても実際に手を動かして運用してみないとわからないことは多いです。

始めるといっても最初から分厚い本に手を出して完璧を求める必要はありません。(私の経験上、TDDは形から入ると挫折します)
APIであればエンドポイントで正常1本、フロントであれば画面の初期表示のテストなど簡単なものを1つ作るところからスタートさせましょう。

最近のプログラム言語やフレームワークであればテストライブラリがあると思うので、それを調べてとにかく1つテストを書いてみましょう。
最初から高いカバレッジを求める必要はありません。

テストがない状態であれば、正常のテストが1つあるだけでかなり状況が変わります。
例えば機能AとBで使っている共通コンポーネントを機能Cからも使おうと思って共通コンポーネントを修正したとします。
その時、AやBも含めてリグレッションテストをすればよいのですが、規模が大きく複雑なシステムの場合、手動でテストをしていたら漏れてしまう可能性が高いです。漏れなかったとしても影響範囲の調査や手動テスト工数が膨大になります。

そういうときに各機能に正常系1件だけでもテストがあると、対応が漏れている機能のテストが落ちて気づける可能性があります。
もちろん正常系1本だとテスト部分は問題なく動作して気づけないこともあります(レスポンスは正常だけど一部の項目が壊れている場合など)
ただ、テストがないと確実に気づけないので大きな第一歩です。(宝くじ、買わないと当たる確率は0%です。みたいな感じです。)

手動テストだけやっていると、「テスト=今回開発したものの動作確認」という意味が強いですが、テストコードを書いて自動化しておくと「テスト=以降、機能の動作を保証するもの」という意味となり、テストコードを書いた以降に不意に壊れることを防ぐことができるようになります。
この感覚が大事だと思います。この感覚が身につくと、テストコードがないコードを触るときに既存を壊してしまっても気づけない恐怖で手が出せなくなります。

まとめ

テストコードについての記事は山のようにあります。そしてテストコード(特にTDD)に関しては否定的な記事も多いと感じます。

もちろん開発しているプロダクトの性質や開発現場の状況によってテストコードを導入することの善し悪しは異なると思います。
ただ、少なくともネガティブな記事に影響されて自分で手を動かすことなくテストコードを悪だと思わないでほしいなと思いこの記事を書きました。

近年では様々な言語でテスト用ライブラリが充実してきており、手軽にテストコードが書けるようになってきています。
ぜひ、自分の手でテストコードを書いてみてテストコードがある開発の感覚を掴んでいただければと思います。

24
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ham0215
Webエンジニアやってます。仕事では主にバックエンド開発をRailsで行っています。仕事で使う機会は少ないですが、フロント開発ではReact、Typescriptを使っています。
vis-its
独自技術ideagramを用いて、人々の「創造性」や「目利き力」の定量化を行い、イノベーター人材の発掘/育成、科学的イノベーション創発支援を行っています。

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
24
Help us understand the problem. What is going on with this article?