blog.mtb-production.info

僕のやったこと、考えたこと、興味のあることについて書いています。

factory_boyについての現状の理解を吐き出す

ここ2日くらい、しばらくぶりにユニットテストを書いている。と言っても、そもそもユニットテストを書いた経験は少ないので、ユニットテストってどう書くんだっけ。と言うところからの再開だった。

開発は、いつものようにPythondjangoで、ユニットテストを書く中でfactory_boyを使っている。その中でfactory_boyってなんだっけ、となった。少し期間が空くと忘れてしまう。前も同じような疑問をもった記憶があるし、思い出すのに時間がかかったり、時間短縮のために再び人に聞いたり、と、なかなか効率が悪い感じがある。一回やったことは、二回目以降にサクッと思い出してサクサク進めたい。

と言うわけで、次に使うときにサクッと思い出せるように今の理解を書き出しておこうと思う。

  • factory_boyは、ユニットテストを書くときに便利。
    • factory_boyは、factoryパターンのクラスを作るための抽象クラスのライブラリ
    • factory_boyを使うとdjangoのmodelにfactoryパターンを適用できる
    • factory_boyを使うと、ユニットテストがデータベースの変更に強くなる。
      • factory_boy(と言うかfactoryパターン)を使わずにユニットテストを書いていると、データベースのカラム追加の時とか辛くなる。
      • 例えば、djangoでデフォルト値の無い、nullが許可されてないカラムを追加すると、そのモデルを使ってテストしてる部分を全体的に修正することになる。辛い。
      • 事前に作ったテストデータを使ってる時はそのテストデータも修正が必要になって、さらに辛い。
    • factory_boyを使うと、楽にテストデータを作れる。
      • 例えば、別のテーブルと依存関係をもつデータを作るとき、依存先のテーブルに参照するデータがないと、データを作れない。ユニットテストのテストケース1つ1つに対して、毎回作るのはわかりと辛い。factory_boyで、依存先のデータを勝手に作るテンプレを書いておけば、あとは勝手にテンプレを作るようにできる。
      • あと、文字列を自動で生成して、レコードを増やすようなのも楽にできる。factory_boyで、ランダム文字列を生成して属性につめるように書いておけばよい。
      • 最新のドキュメントを読むと、build_batchというメソッドを使って、一括で大量のデータを作ることもできる様子
    • データベースの変化に強いユニットテストを作るためにfactory_boyは便利。
      • 逆にほとんどデータベースが変化しないようなシステムでfactory_boyは必要か?と言われると、別に必要ではない。
      • そもそもfactory_boyは、必要かどうかの話ではなくて、使っておくと便利になる。という話。
      • そして、factory_boyそのものを導入するのはそこまで難しくないし、システムがほとんど変化しないとしても、RDBを使ってリレーションが複雑になるならfactory_boyを使っておく方が開発の効率は上がる。今のところ、あんまりいれない理由は思い浮かんでいない。

今日のところの理解はこんな感じです。