0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

horikawa hitoriAdvent Calendar 2022

Day 4

なぜ自分はテストコードを書くのか

Posted at

はじめに

自分がエンジニアになった頃から担当しているプロジェクトではテストコードが当たり前に書かれていました
あまりなぜ書いているか意識せずなんとなく書いていたので、なんのために書いているのか自分なりに考えてみました

1. 不具合を未然に防ぐため

開発時にテストが回るため不具合を未然に防げる可能性が高まります
コードの変更によって意図していない箇所に影響があった場合もテストによって防ぐことができます

2. リファクタリングやバージョンアップの難易度が下がる

テストによってコードの振る舞いが保証されているので、リファクタリングやバージョンアップによって壊れることを防げます
テストコードがないプロジェクトでのリファクタやバージョンアップはリスクが大きくあまりやりたくないです

3. テストコード自体が仕様書として残る

ほとんどの場合にはテストコードにはテストケースと期待する振る舞いを書きます
これによってテストコードを見ることで、実装の仕様を確認することできます
テストのないプロジェクトでは実際に書かれている内容から動作を推測する必要があるので、テストがあるだけで開発自体がやりやすくなると思っています

4. 人間によるテストを減らすことができる

機能の実装時に人間によるテストを行いますが、テストコードがないと改修した箇所以外も時間をかけて人間が確認する必要が出てきます
テストコードがあれば、テストコードに任せてしまうことができるので人間によるテストは最小限で済むと思います

5. コードの品質自体を上げる

テストを書こうと思うとどうしてもテストし易いコードを書く必要が出てきます
テストし易いようにモジュールを分割するなど設計面でもテストを意識することでコード自体の品質が上がるのかなと思っています

いつテストを書くのか

  • 人間がテストするよりもテストコードに任してしまったほうが早いところ
  • 複雑なロジックになってしまったことろ
  • セキュリティ上重要なところ
  • 不具合を呼ぶ予感がするところ

テストを書かない場所

  • バリデーションなどのフレームワークの設定で済む場合
  • 自動生成されており手を加えていない場合
  • すでに別のテストで信頼できる場所
  • テストカバレッジを上げるためだけに書く場所

まとめ

当たり前のことが多くなってしまいましたが、自分はこのような理由があってテストを書いています
こういったメリットも理解して今後もテストを書いていきたいと思います

0
0
0

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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?