この記事の続きはG's ACADEMY Advent Calendarの14日目に公開します。
この記事用にそもそもの話を掘り下げようと思ったら、長くなったので前置きを分けました。
はじめに
私が初めてLaravelを触ったのはおよそ1年前です。
ちょうど去年の今頃は、フレームワークとかMVCとかちんぷんかんぷんです。とにかくサンプルコードをコピペしてきてなんとかいじって動かす、ということを延々とやっていました。
その後だんだんLaravelのお作法にも慣れてきて、全てを画面で動かしながらデバッグすることに辟易してきたのが今から半年前。
それからつい先日まで、テスト書きたいけど何からやればいいのやら…と途方にくれていた私が開眼した（と思う）ので、そのことについて書きます。
私のようなケースはマイノリティかも知れませんが、テストがなんとなく書けなかったこのモヤモヤの正体を言語化できればと思います。他にもテストでモヤっている人の何かのきっかけになれば。。。
結論
結論から言うとPHPフレームワークLaravel Webアプリケーション開発という本で「11章 TDDの実践」の中身を写経してみたら、結構スッと入ってきた、というだけです。
体感として本当に抵抗なく、テストってこう言うことか！と分かったので、じゃあ逆になぜ分からなかったのかが気になったので考察してみた次第です。
対象になりそうな方
- テストを書くのに興味あるけど、何から始めればいいか分からない人
- Laravelの基本的なお作法が分かっている人
なぜテストが書けなかったのか
テストコードを書く、という感覚が掴めなかった私にとって、課題は下記の3つでした。
- そもそもテストのお作法（構文、使う関数）がよく分かっていなかった
- すでにある実装に対して、テストを書くために何をすればいいか分からなかった
- どういうテストが必要か分かっていなかった（テストの種類に対する理解がない）
でも今考えると、両方とも私の中では問題の根っこはひとつでした。すなわち テストの書き方は実装の内容によって変わる ということです。テストの構文や使う関数は調べればいくらでも出てきます。しかし、どこでどうやって使えばいいのかイメージができない。
すでに自分で実装したコードに対してテストを書こうとしても、ググって出てきたサンプルコードは当然使えませんし、一般的な書き方を調べてもピンと来ませんでした。
これは私の勉強スタイルとの相性にも問題があったかもしれません。私のよくやる勉強方法はこんな感じです。
- 使いたい部分をとりあえずコピペしたり写経したりして、それっぽいサンプルを動かす
- それをいろいろいじって自分のアプリケーション上で動くようにする
- 上記の過程で何となく仕組みを理解していく
- 自分で最初から書いてみる（繰り返す）
これだと、まず自分の実装に使えそうなテストコードを探すことになります。でも自分の実装に対してどういうテストを書けばいいか全くイメージできていないので、使えそうなテストを探し出せない。
そうかと言って簡単なサンプルアプリケーションをテストも含めて写経してみたところで、このサンプルのケース以外ではどうやって書くの？という状態でした。こちらに関しては覚えれば済む話で、テストで使う構文や関数に対する知識が圧倒的に足りなかったのだと思います。
上記のような状況の中さらに悪いのは、大抵の場合自分で書いた実装は テストが書きやすい実装になっていない ことです。これにより結局何をすればいいのか分からず混乱します。
こうして私は、必要と知りつつテストを書くことから、なんとなく逃げていました。。。
なぜLaravelでやるのか
- Laravelの機能でDBのテストも含めたテストが簡単に書ける
- Laravelのお作法に慣れ親しんでいれば直感的に使える（それの良し悪しはおいといて）
私にとっては慣れているフレームワーク上で書けたので戸惑いが少なかったように思います。
また、書籍の11章の中で、特に下記のようなところがテスト初心者の私にとって易しいポイントでした。
- テストありきで設計していくのでテストを書く過程が追える
- 小さく小さくテストを書いていくのでテスト自体が単純で書きやすい
- サクサクとテストが通って気持ちいい感覚が得られる
- 何より、テストを書くための準備について触れてくれていた
気がつくと、テスト書くの楽しいかも〜！！となってました。
さらに9章でもう少し細かく実践できる
11章を終えた後9章に戻ると、Laravelでのテストの仕組みについて、より詳細な説明を読むことができます。
9章は11章と違ってハンズオンでテンポよく進む感じではなかったし、初心者には少し難しい部分があると感じました。脱初心者くらいの方に良い本なのかもしれません。
ということで、TDDを通してテストを書くことで「テスト書けない問題」の克服のための第一歩にしてみてはいかがでしょうか。次の記事ではもう少し具体的に書いていきます。
ちなみにTDDについては賛否両論だった
社内勉強会でこの本を使ったので、TDDに関してはいろんな意見が出ていました。
- テストが動く安心感がある
- エンジニアにとって精神衛生上良い！
- 現場ではTDD難しいよね、、（既存サービスの保守改善とかだとなかなか実践できない）
- 新規開発の時はテンポ良く開発できて楽しそう
などなど。
個人的にはテスト書いて実装して、を繰り返しながら開発していくTDDは、螺旋階段をどんどん登っていくようなイメージで楽しかったのでした。自分でミニアプリ作るときにTDDでやってみたいと思いました！
この記事の続きはG's ACADEMY Advent Calendarの14日目に公開します。