YK
Uploaded byYusuke Kagata
4,262 views

テストコードの DRY と DAMP

@PHPerKaigi 2022

Embed presentation

テストコードの DRY と DAMP @PHPerKaigi 2022, 2022-04-11
誰？ • 加賀田 裕介 @_heartyfluid • 今は Web アプリエンジニア • 今は不動産とか IoT とかの会社に勤務 • 直近では自社サービスのひとつを PHP7 + CakePHP3 から PHP8 + CakePHP4 にひとりで移行作業中 • 最近の趣味はドイツ語
ここまでのあらすじ： 気がついたらユニットテストおじさんに • 転職 • そこには前任者が書き残した壊れたユニットテストが • 自分の作業用にテストを書き足す • 自分のテスト結果が見づらくなるので、壊れたテストも直す • 「なんか今度の新入りはテストに強いらしい」 • 職場でいわゆる「ユニットテストおじさん」の地位を確立 • .oO(業務でテスト書くの初めてなんですけどね… • あわててテスト芸を仕込む日々
ある日のコードレビュー（※再現） • CakePHP のコントローラーのシンプルなテストをレビューす る 🤔 🤔 たとえば、この間にコードが増えると $this->post() に渡される引数がなんだったか わかりにくくなりそう
ある日のコードレビュー（※再現） • どちらかというとこうしてほしい気持ち 👍 👍 どう読んでも誤解がない
反論が予想（妄想）される • 内なるレビュイー「DRY 原則って知ってますか」
歯切れの悪い In My Opinion 「わかります。おっしゃりたいことはよくわかります。まともな神経のプロ グラマーなら、同じ文字列リテラルを2回書くなんて生理的に受け付けないで すよね。”Don’t Repeat Yourself” すなわち DRY 原則というやつですよね知ってます。でもちょっと立ち止 まって考えたいんですけどいいですか、同じリテラルを 2回書かないのってたとえば「その値を変更したくなったとき に同じ変更を2箇所に施さないといけないのはだるいから」だったりするじゃ ないですか、でもね、このテストってパス /users/add に HTTP リクエストを 投げてみるというのがそもそもの趣旨なわけでしょう、そうすると文字列リ テラル ‘/users/add’ を変更したくなるケースって実はそんなに想定しなくても いいと思うんですよ。えっいや100%保証できるわけじゃないですけど…でも まあそうだとするとですよ、その行でどんな値になっているかその1行を読ん だだけではわからない変数よりも、値をベタッと書いてあるほうが読み手に は読みやすいんじゃないかなあと思うんですよね。えっ大差ない？お前だ け？気合いの問題？ええっと…（続
もうひとつの原則：DAMP
もうひとつの原則：DAMP • DAMP; Descriptive And Meaningful Phrases 「説明的かつ意味がわかりやすい言い回し」 良いテストとは変化しないように設計されるものであり、そして実際、テスト対象システムが変化す る際にはテストが破綻することが通常は望ましい。したがってテストコードに関しては、本番環境向 けのコードほど DRY の恩恵はない。 さらにテストの場合、複雑となった場合のコストがより大きい。つまり、(…) テストは自立しなけれ ばならず、正しいことが自明でなければバグを出すリスクがある。(…) テストが正しく動作している ことを担保するためにテスト自体にテストが必要と感じられるほどテストが複雑になり始めたら、何 かが間違っている。 Titus Winters ほか. Google のソフトウェアエンジニアリング. オライリー・ジャパン, 2021. これが 言いたいことだった
乱暴に整理する DRY DAMP • コードの重複を避ける • コードは簡潔になる • 変更時にも一貫性を壊さない • 誤読のリスクは残るかもしれない • プロダクトコード向き（？） • コードの重複をいとわない • コードは冗長になる • 一貫性の担保が手間かもしれない • そうとしか読めないようなコード • テストコード向き（？） 現実には、局面ごとに バランスをとる必要性
参考文献 • Titus Winters ほか. Google のソフトウェアエンジニアリング. オライリー・ジャパン, 2021. • 日本語で DAMP についてまとまった解説を読めるのがこちら • Vladimir Khorikov. “DRY vs DAMP in Unit Tests”. Enterprise Craftsmanship. 2020年6月8日. https://enterprisecraftsmanship.com/posts/dry-damp-unit-tests/ • プロダクトコードは DRY でテストコードは DAMP …というわけではない、という解説。How は DRY に、What は DAMP に書きましょう • David Thomas ほか. 達人プログラマー（第2版）. オーム社, 2020. • DRY 原則といえば『達人プログラマー』。DRY も改めてふりかえると、単に「同じコードを2回書くな」という以上の 話を含んでいますね • 宍戸里佳. 英語と一緒に学ぶドイツ語. ベレ出版, 2012. • ところで、 Don’t Repeat Yourself の Yourself っていまいち必要性がわからないことないですか。ドイツ語文法の「再帰 動詞」を学ぶとより立体的に理解できます（※個人の感想です）。ドイツ語はいいぞ

More Related Content

PDF
BuildKitの概要と最近の機能
byKohei Tokunaga
 
PDF
こわくない Git
byKota Saito
 
PPTX
世界一わかりやすいClean Architecture
byAtsushi Nakamura
 
PDF
開発速度が速い #とは（LayerX社内資料）
bymosa siru
 
PDF
テスト文字列に「うんこ」と入れるな
byKentaro Matsui
 
PDF
コンテナの作り方「Dockerは裏方で何をしているのか？」
byMasahito Zembutsu
 
PDF
SolrとElasticsearchを比べてみよう
byShinsuke Sugaya
 
PDF
マイクロにしすぎた結果がこれだよ！
bymosa siru
 
BuildKitの概要と最近の機能
byKohei Tokunaga
 
こわくない Git
byKota Saito
 
世界一わかりやすいClean Architecture
byAtsushi Nakamura
 
開発速度が速い #とは（LayerX社内資料）
bymosa siru
 
テスト文字列に「うんこ」と入れるな
byKentaro Matsui
 
コンテナの作り方「Dockerは裏方で何をしているのか？」
byMasahito Zembutsu
 
SolrとElasticsearchを比べてみよう
byShinsuke Sugaya
 
マイクロにしすぎた結果がこれだよ！
bymosa siru
 

What's hot

PDF
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
byTakuto Wada
 
PDF
暗号技術の実装と数学
byMITSUNARI Shigeo
 
PPTX
SPAセキュリティ入門～PHP Conference Japan 2021
byHiroshi Tokumaru
 
PDF
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう！（PostgreSQL Conference Japan 2023 発表資料）
byNTT DATA Technology & Innovation
 
PDF
シリコンバレーの「何が」凄いのか
byAtsushi Nakada
 
PDF
例外設計における大罪
byTakuto Wada
 
PPTX
分散システムについて語らせてくれ
byKumazaki Hiroki
 
PDF
IT系エンジニアのためのプレゼンテーション入門
byMasahito Zembutsu
 
PPTX
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）
byNTT DATA Technology & Innovation
 
PDF
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
byTakahiko Ito
 
PDF
TLS, HTTP/2演習
byshigeki_ohtsu
 
PDF
Redmine にいろいろ埋め込んでみた
byKohei Nakamura
 
PDF
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
byTakuto Wada
 
PDF
xOps: エンジニアがスタートアップの成長の原動力となる日
byTakaaki Umada
 
PDF
Linux女子部　systemd徹底入門
byEtsuji Nakai
 
PDF
新たなgitのブランチモデル「Git Feature Flow」！Git Flow,Git Hub Flow,Git Lab Flowを超えれるか？
bynaoki koyama
 
PPTX
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
byShota Shinogi
 
PPTX
Redisの特徴と活用方法について
byYuji Otani
 
PDF
分散トレーシング技術について（Open tracingやjaeger）
byNTT Communications Technology Development
 
PDF
TDD のこころ
byTakuto Wada
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
byTakuto Wada
 
暗号技術の実装と数学
byMITSUNARI Shigeo
 
SPAセキュリティ入門～PHP Conference Japan 2021
byHiroshi Tokumaru
 
pgvectorを使ってChatGPTとPostgreSQLを連携してみよう！（PostgreSQL Conference Japan 2023 発表資料）
byNTT DATA Technology & Innovation
 
シリコンバレーの「何が」凄いのか
byAtsushi Nakada
 
例外設計における大罪
byTakuto Wada
 
分散システムについて語らせてくれ
byKumazaki Hiroki
 
IT系エンジニアのためのプレゼンテーション入門
byMasahito Zembutsu
 
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）
byNTT DATA Technology & Innovation
 
Elasticsearch の検索精度のチューニング 〜テストを作って高速かつ安全に〜
byTakahiko Ito
 
TLS, HTTP/2演習
byshigeki_ohtsu
 
Redmine にいろいろ埋め込んでみた
byKohei Nakamura
 
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
byTakuto Wada
 
xOps: エンジニアがスタートアップの成長の原動力となる日
byTakaaki Umada
 
Linux女子部　systemd徹底入門
byEtsuji Nakai
 
新たなgitのブランチモデル「Git Feature Flow」！Git Flow,Git Hub Flow,Git Lab Flowを超えれるか？
bynaoki koyama
 
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
byShota Shinogi
 
Redisの特徴と活用方法について
byYuji Otani
 
分散トレーシング技術について（Open tracingやjaeger）
byNTT Communications Technology Development
 
TDD のこころ
byTakuto Wada
 

テストコードの DRY と DAMP

  • 1.
  • 2.
    誰？ • 加賀田 裕介@_heartyfluid • 今は Web アプリエンジニア • 今は不動産とか IoT とかの会社に勤務 • 直近では自社サービスのひとつを PHP7 + CakePHP3 から PHP8 + CakePHP4 にひとりで移行作業中 • 最近の趣味はドイツ語
  • 3.
    ここまでのあらすじ： 気がついたらユニットテストおじさんに • 転職 • そこには前任者が書き残した壊れたユニットテストが •自分の作業用にテストを書き足す • 自分のテスト結果が見づらくなるので、壊れたテストも直す • 「なんか今度の新入りはテストに強いらしい」 • 職場でいわゆる「ユニットテストおじさん」の地位を確立 • .oO(業務でテスト書くの初めてなんですけどね… • あわててテスト芸を仕込む日々
  • 4.
  • 5.
  • 6.
  • 7.
    歯切れの悪い In MyOpinion 「わかります。おっしゃりたいことはよくわかります。まともな神経のプロ グラマーなら、同じ文字列リテラルを2回書くなんて生理的に受け付けないで すよね。”Don’t Repeat Yourself” すなわち DRY 原則というやつですよね知ってます。でもちょっと立ち止 まって考えたいんですけどいいですか、同じリテラルを 2回書かないのってたとえば「その値を変更したくなったとき に同じ変更を2箇所に施さないといけないのはだるいから」だったりするじゃ ないですか、でもね、このテストってパス /users/add に HTTP リクエストを 投げてみるというのがそもそもの趣旨なわけでしょう、そうすると文字列リ テラル ‘/users/add’ を変更したくなるケースって実はそんなに想定しなくても いいと思うんですよ。えっいや100%保証できるわけじゃないですけど…でも まあそうだとするとですよ、その行でどんな値になっているかその1行を読ん だだけではわからない変数よりも、値をベタッと書いてあるほうが読み手に は読みやすいんじゃないかなあと思うんですよね。えっ大差ない？お前だ け？気合いの問題？ええっと…（続
  • 8.
  • 9.
    もうひとつの原則：DAMP • DAMP; DescriptiveAnd Meaningful Phrases 「説明的かつ意味がわかりやすい言い回し」 良いテストとは変化しないように設計されるものであり、そして実際、テスト対象システムが変化す る際にはテストが破綻することが通常は望ましい。したがってテストコードに関しては、本番環境向 けのコードほど DRY の恩恵はない。 さらにテストの場合、複雑となった場合のコストがより大きい。つまり、(…) テストは自立しなけれ ばならず、正しいことが自明でなければバグを出すリスクがある。(…) テストが正しく動作している ことを担保するためにテスト自体にテストが必要と感じられるほどテストが複雑になり始めたら、何 かが間違っている。 Titus Winters ほか. Google のソフトウェアエンジニアリング. オライリー・ジャパン, 2021. これが 言いたいことだった
  • 10.
    乱暴に整理する DRY DAMP • コードの重複を避ける •コードは簡潔になる • 変更時にも一貫性を壊さない • 誤読のリスクは残るかもしれない • プロダクトコード向き（？） • コードの重複をいとわない • コードは冗長になる • 一貫性の担保が手間かもしれない • そうとしか読めないようなコード • テストコード向き（？） 現実には、局面ごとに バランスをとる必要性
  • 11.
    参考文献 • Titus Wintersほか. Google のソフトウェアエンジニアリング. オライリー・ジャパン, 2021. • 日本語で DAMP についてまとまった解説を読めるのがこちら • Vladimir Khorikov. “DRY vs DAMP in Unit Tests”. Enterprise Craftsmanship. 2020年6月8日. https://enterprisecraftsmanship.com/posts/dry-damp-unit-tests/ • プロダクトコードは DRY でテストコードは DAMP …というわけではない、という解説。How は DRY に、What は DAMP に書きましょう • David Thomas ほか. 達人プログラマー（第2版）. オーム社, 2020. • DRY 原則といえば『達人プログラマー』。DRY も改めてふりかえると、単に「同じコードを2回書くな」という以上の 話を含んでいますね • 宍戸里佳. 英語と一緒に学ぶドイツ語. ベレ出版, 2012. • ところで、 Don’t Repeat Yourself の Yourself っていまいち必要性がわからないことないですか。ドイツ語文法の「再帰 動詞」を学ぶとより立体的に理解できます（※個人の感想です）。ドイツ語はいいぞ

Editor's Notes