$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Djangoで「良い」Factoryを書きたい
Search
Yasshieeee
June 20, 2024
Technology
0
70
Djangoで「良い」Factoryを書きたい
みんなのPython勉強会#105でのLT資料
Yasshieeee
June 20, 2024
Tweet
Share
More Decks by Yasshieeee
See All by Yasshieeee
「他の人が理解できる」を掘り下げる_リーダブルコード LT会 - vol.4
yacpotato
0
83
はんなりPython 47回LT回
yacpotato
0
180
Other Decks in Technology
See All in Technology
ChatGPTで論⽂は読めるのか
spatial_ai_network
9
28k
Kubernetes Multi-tenancy: Principles and Practices for Large Scale Internal Platforms
hhiroshell
0
120
MLflowで始めるプロンプト管理、評価、最適化
databricksjapan
1
250
1人1サービス開発しているチームでのClaudeCodeの使い方
noayaoshiro
1
160
モダンデータスタック (MDS) の話とデータ分析が起こすビジネス変革
sutotakeshi
0
500
re:Invent 2025 ~何をする者であり、どこへいくのか~
tetutetu214
0
220
[デモです] NotebookLM で作ったスライドの例
kongmingstrap
0
150
Lambdaの常識はどう変わる?!re:Invent 2025 before after
iwatatomoya
1
560
AWS re:Invent 2025で見たGrafana最新機能の紹介
hamadakoji
0
390
年間40件以上の登壇を続けて見えた「本当の発信力」/ 20251213 Masaki Okuda
shift_evolve
PRO
1
130
打 造 A I 驅 動 的 G i t H u b ⾃ 動 化 ⼯ 作 流 程
appleboy
0
350
.NET 10の概要
tomokusaba
0
110
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
1.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.2k
Making Projects Easy
brettharned
120
6.5k
Side Projects
sachag
455
43k
Building Flexible Design Systems
yeseniaperezcruz
330
39k
Context Engineering - Making Every Token Count
addyosmani
9
520
KATA
mclloyd
PRO
33
15k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Transcript
Djangoで「良い」 Factoryを書きたい やっしー みんなのPython勉強会#105
自己紹介 名前 やっしー https://github.com/YaCpotato https://www.leadingmark.jp/ 現在業務でDjangoを使っています その他Rails, Nuxt.jsなどなど、3年ほどのWebエンジニアです :@Yasshieeee
今回の発表はトークメインで、発表しきれないことなど具体 例はQiitaに書いてあります! https://qiita.com/leadingmark_yashiro/items/0e38b0cbccd88505c9e8
「良い」Factory、書きたいですよね 問題提起:テスト導入初期、新しい viewsのテストの度にFactoryが修正される → 割れ窓的にできがちになる不完全な Factory → テストだけに集中したいのに Factoryもみなければならず、コスト増 → 絶賛改修中の機能周りのモデルだった場合、コンフリクトの可能性 ここ最近書くことが多くなり、知見をシェアさせていただきます。 ※本当にモデルに仕様変更はいったらしょうがないですコレ
「良い」Factoryとはなにか考える • 読みやすい、修正しやすい →作って終わりではない。使い続ける、変化に対応させるため • 使い方がわかりやすい →自分にしかわからないオレオレ Factoryはダメ (大体みんな同じ書き方にはなるのだが、 細かい部分で自身の想定との差異はコー
ディングが統一されない原因となる。細かいから指摘する優先度が下がる ) • データは現実に即している →自動生成してくれるFaker、便利だけれど、そのデータ、実際に入りうるの?
読みやすい、修正しやすい • 書き方(ルール)が統一されている ◦ f文字列、.format()など、文字列内の変数使用の方法 ◦ fakerの使用メソッドの統一 ◦ 変数をどう受け取り、どう作るか
使い方がわかりやすい DocStringを使おう! 引数としてカラム名で渡せば、 Factoryで参照し ていなくても使ってくれるが、極力書いてあげた い 上記でもこれができてしまう →
データは現実に即している Fakerから現実に即した出力を満たすメソッド探すの、つらいけど頑張らないとですね https://faker.readthedocs.io/en/master/locales/ja_JP.html# こういうときはぶっちゃけrandomパッケージ使ってます。 → ChoiceField:選択肢形式。データベース的に varchar
そのテストのための要件を満た すFactoryは、必ずしも他のテ ストの要件を満たすとは限らな い →新しいviewsのテストの度に 修正されがちになる
ではどうするか 新しいテスト書く度に仕様変更されないモデ ルのFactoryが修正されないために • テスト、Factoryにもコーディングルール • Factoryも詳細設計 • viewsではなくmodelのテストをまず書き、 Factoryを使い倒す