ここ２日くらい、しばらくぶりにユニットテストを書いている。と言っても、そもそもユニットテストを書いた経験は少ないので、ユニットテストってどう書くんだっけ。と言うところからの再開だった。
開発は、いつものようにPythonとdjangoで、ユニットテストを書く中でfactory_boyを使っている。その中でfactory_boyってなんだっけ、となった。少し期間が空くと忘れてしまう。前も同じような疑問をもった記憶があるし、思い出すのに時間がかかったり、時間短縮のために再び人に聞いたり、と、なかなか効率が悪い感じがある。一回やったことは、二回目以降にサクッと思い出してサクサク進めたい。
と言うわけで、次に使うときにサクッと思い出せるように今の理解を書き出しておこうと思う。
- factory_boyは、ユニットテストを書くときに便利。
- factory_boyは、factoryパターンのクラスを作るための抽象クラスのライブラリ
- factory_boyを使うとdjangoのmodelにfactoryパターンを適用できる
- factoryパターンを適用すると、インスタンスの生成とインスタンスの属性や振る舞いを切り離せる。
- 要するに、インスタンスのテンプレが作れるような感じ。
- factory_boyを使うと、ユニットテストがデータベースの変更に強くなる。
- factory_boy（と言うかfactoryパターン）を使わずにユニットテストを書いていると、データベースのカラム追加の時とか辛くなる。
- 例えば、djangoでデフォルト値の無い、nullが許可されてないカラムを追加すると、そのモデルを使ってテストしてる部分を全体的に修正することになる。辛い。
- 事前に作ったテストデータを使ってる時はそのテストデータも修正が必要になって、さらに辛い。
- factory_boyを使うと、楽にテストデータを作れる。
- 例えば、別のテーブルと依存関係をもつデータを作るとき、依存先のテーブルに参照するデータがないと、データを作れない。ユニットテストのテストケース１つ１つに対して、毎回作るのはわかりと辛い。factory_boyで、依存先のデータを勝手に作るテンプレを書いておけば、あとは勝手にテンプレを作るようにできる。
- あと、文字列を自動で生成して、レコードを増やすようなのも楽にできる。factory_boyで、ランダム文字列を生成して属性につめるように書いておけばよい。
- 最新のドキュメントを読むと、build_batchというメソッドを使って、一括で大量のデータを作ることもできる様子
- データベースの変化に強いユニットテストを作るためにfactory_boyは便利。
- 逆にほとんどデータベースが変化しないようなシステムでfactory_boyは必要か？と言われると、別に必要ではない。
- そもそもfactory_boyは、必要かどうかの話ではなくて、使っておくと便利になる。という話。
- そして、factory_boyそのものを導入するのはそこまで難しくないし、システムがほとんど変化しないとしても、RDBを使ってリレーションが複雑になるならfactory_boyを使っておく方が開発の効率は上がる。今のところ、あんまりいれない理由は思い浮かんでいない。
今日のところの理解はこんな感じです。
