# テストって何がいいのか考えたごみめも
###### tags: `くそめも`

テストって何がいいの

### 品質保証ができる
アプリ作る時って利害関係者のみんながみんな実装のコードを全部読んで理解できる人たちじゃないので、こういうテストをしていて、そのうちの何%に通ってますとか、言えるだけでちゃんと作ってるよっていうのをわかってもらうことができる気がする。

### 人が書いたコードだと一から読むのは大変だけど、テストから読むとだいたい何をしてるのかわかる。
正直全部コード読んでレビューしてる時間ないことよくあるよね。そんな時にこのテスト通ってますって言ってくれるととっても嬉しい。
もちろん全部コードレビューするのが一番いいのだけど、そんなときでもテストを先に読むと何がしたかったのかわかるので、実装を読むのが楽になる気がする。

### コツコツテストを書いてるとリグレッションテストが簡単にできる。その結果、継続的にプロダクトを改善できる
ある部分を変えたら他の部分が壊れることがよくある。
影響の大きい変更をする時は影響調査を事前にするはずだけど、完璧に調査できる自信がない。そんな時テスト通っただけでめちゃくちゃ安心する。

すごく複雑でテストが書かれてない、いつ壊れるかわからないアプリをメンテしろって言われたら、追加機能のアイデアを思いついても、壊したくないからって実装したくなくなるよね。

安心してコードを編集できるということは、リファクタリングしたり、機能を追加したり、パフォーマンスチューニングをしたりする心理的なハードルがとっても下がるということ。結果的に常にコードベースを改善したり、より良い機能を実装したりするモチベーションになるよって話。

余談: そういや昔お仕事で、デバッグするために一部をコメントアウトしてたのを忘れてそのままプロダクションに乗せてアプリごと落としたことがある。テスト書いとけば一瞬で気づけたのにって後悔した。

### ちゃんと書けてるとテストコード = コードの要件定義書になる。
jestだと

describe('sortArrayContent', () => {
    it('配列の中身をアルファベット順に並べる', () => {
        //テストコード
    });
    it('配列にnullがあったらUnsortableElementErrorエラーを吐く', () => {
        //テストコード
    });
    it('配列が空の時は何もしない', () => {
        //テストコード
    });
})

みたいに、1要件1テストになっていくことが多いと思う。ユニットテストは特にこんな感じになる。
後からチームに入ってきた人とか、コードベース把握するのにある程度時間がかかると思うんだけど、テストコードをふわーって見てるだけでなんとなくの感じはわかる。

### 結論: 自信がつく
利用者視点では、ちゃんと作られてるんだって安心できるし
開発者視点では、今はちゃんと動いてるし、壊れたらすぐに気づけるしって安心できる
これはまともなアプリだって自信を持てるのが一番のポイントな気がする。

### 疑問: でも個人で小規模開発してたらあんまり恩恵なくね
確かに一理ある。

一人でやってて頭の中で管理できるくらいのコードベースの量ならテストなんて時間かかるだけじゃねって思ったそこのあなた。

でもね

一旦開発中断して1年後とかに追加のアイデアとか思いついて、開発再開しようってなったとしよう。

一年前の自分が書いたコードなんて他人が書いたコードと大差ないぜ。
このコード、何がしたかったんだ。。。
なんてことはよくあるんだ。(経験談)。
だから無駄ではないと思うぞ。

個人開発で、小規模で、今しか使わないアプリを作ってるならテストなんて書かなくていいと思う。
でもさ、職業エンジニアがそんなアプリしか作らないことなんていないと思うんだ。

### 要するに
テスト書け。