SymfonyDIを利用してMail送信クラスをインテグレーションテストする：前置き編

コードの解説を行っている続編はこちら

前置き

皆さんテスト書いてますか？

TDDでバリバリ開発しています！という人は少ないのではないかと思います。

TDDをなかなか実践できない問題の１つにテストを書くメリットを感じ辛いというのがあるのではないかと思います。

確かに効果を感じ辛い部分もありますが、逆にすごく効果的に機能する場合もあります。

今回はメリットを感じやすいメールのインテグレーションテストを紹介したいと思います。

普通にブラウザテストを行う場合、メールを送信するためにユーザー登録フォームに入力したり、申し込みフォームを入力したりと、面倒な操作を行わないといけないケースが大半だと思います。

ユーザー登録など１度しか行うことのできない操作の場合だと登録処理が完了した後、テストのためにDBのデータを削除して再度実行！なんて非常に面倒です。

操作するのが面倒なのでデバッグ用のコントローラーでも用意して、そこからメール送信のメソッドを呼び出すこともできますが、毎回そういうのを書くのも面倒です。

そこで是非やっていただきたいのが、登場するのがメールのインテグレーションテストです！

この記事の続編に書いてある方法を実践すると以下のメリットがあります。

タイトル通り扱うのはインテグレーションテストであり、ユニットテストではありません

このテストの目的は、ある引数を渡したら想定されたメールが送信されるか確認するためのテストを行いたいのです。（ただし、続編記事で書いている通り実際にはメールを送らず代替手段で確認を行います）

は今回確認したいことではありません。

テンプレートの置き場所やファイル名が間違っていた。

変数は渡してたけど、Twig中での表記が間違っていて動作しなかった

では意味がないですよね。

テストで確認したいことは、

だからです。

※ 決してユニットテストが不要と言っているわけではありません。テストの目的が異なるだけです。

End-toEnd Testすれば？と思う方もいるかもしれませんが、ここではコントローラーのテストを行いたい訳ではないのでやりません。

コードの解説を行っている続編はこちら