テストコードの DRY と DAMP

テストコードの
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 っていまいち必要性がわからないことないですか。ドイツ語文法の「再帰
動詞」を学ぶとより立体的に理解できます(※個人の感想です)。ドイツ語はいいぞ
1 von 11

Recomendados

シリコンバレーの「何が」凄いのか von
シリコンバレーの「何が」凄いのかシリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのかAtsushi Nakada
183.9K views77 Folien
開発速度が速い #とは(LayerX社内資料) von
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)mosa siru
61.5K views18 Folien
例外設計における大罪 von
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
68.6K views37 Folien
世界一わかりやすいClean Architecture von
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean ArchitectureAtsushi Nakamura
47.1K views77 Folien
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive von
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveDXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLiveTokoroten Nakayama
122.3K views99 Folien
エンジニアの個人ブランディングと技術組織 von
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織Takafumi ONAKA
23.4K views40 Folien

Más contenido relacionado

Was ist angesagt?

イベント駆動プログラミングとI/O多重化 von
イベント駆動プログラミングとI/O多重化イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化Gosuke Miyashita
15.4K views78 Folien
イミュータブルデータモデル(入門編) von
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)Yoshitaka Kawashima
185.8K views24 Folien
フロー効率性とリソース効率性について #xpjug von
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugItsuki Kuroda
106.2K views62 Folien
DockerコンテナでGitを使う von
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使うKazuhiro Suga
18.8K views8 Folien
45分間で「ユーザー中心のものづくり」ができるまで詰め込む von
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込むYoshiki Hayama
50.7K views110 Folien
Test Yourself - テストを書くと何がどう変わるか von
Test Yourself - テストを書くと何がどう変わるかTest Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるかTakuto Wada
38.3K views49 Folien

Was ist angesagt?(20)

イベント駆動プログラミングとI/O多重化 von Gosuke Miyashita
イベント駆動プログラミングとI/O多重化イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
Gosuke Miyashita15.4K views
イミュータブルデータモデル(入門編) von Yoshitaka Kawashima
イミュータブルデータモデル(入門編)イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima185.8K views
フロー効率性とリソース効率性について #xpjug von Itsuki Kuroda
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda106.2K views
DockerコンテナでGitを使う von Kazuhiro Suga
DockerコンテナでGitを使うDockerコンテナでGitを使う
DockerコンテナでGitを使う
Kazuhiro Suga18.8K views
45分間で「ユーザー中心のものづくり」ができるまで詰め込む von Yoshiki Hayama
45分間で「ユーザー中心のものづくり」ができるまで詰め込む45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama50.7K views
Test Yourself - テストを書くと何がどう変わるか von Takuto Wada
Test Yourself - テストを書くと何がどう変わるかTest Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
Takuto Wada38.3K views
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 von Takuto Wada
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada148.7K views
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版) von Takuto Wada
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada70.7K views
Where狙いのキー、order by狙いのキー von yoku0825
Where狙いのキー、order by狙いのキーWhere狙いのキー、order by狙いのキー
Where狙いのキー、order by狙いのキー
yoku082539.5K views
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話 von Koichiro Matsuoka
DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話DDD x CQRS   更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka88.2K views
ドメイン駆動設計 ( DDD ) をやってみよう von 増田 亨
ドメイン駆動設計 ( DDD ) をやってみようドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨50.1K views
Dockerからcontainerdへの移行 von Kohei Tokunaga
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga16.7K views
BuildKitによる高速でセキュアなイメージビルド von Akihiro Suda
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda42.6K views
本当は恐ろしい分散システムの話 von Kumazaki Hiroki
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki686.1K views
こわくない Git von Kota Saito
こわくない Gitこわくない Git
こわくない Git
Kota Saito881.5K views
ユーザーインタビューするときは、どうやらゾンビのおでましさ von Yoshiki Hayama
ユーザーインタビューするときは、どうやらゾンビのおでましさユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama8.6K views
世界でいちばんわかりやすいドメイン駆動設計 von 増田 亨
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨14.5K views

Similar a テストコードの DRY と DAMP

とある Perl Monger の働き方 von
とある Perl Monger の働き方とある Perl Monger の働き方
とある Perl Monger の働き方Yusuke Wada
15.5K views46 Folien
ひよこテスト駆動開発(PHPカンファレンス2014) von
ひよこテスト駆動開発(PHPカンファレンス2014)ひよこテスト駆動開発(PHPカンファレンス2014)
ひよこテスト駆動開発(PHPカンファレンス2014)Oonishi Keitarou
4.2K views34 Folien
パフォーマンステストいつやる?? von
パフォーマンステストいつやる??パフォーマンステストいつやる??
パフォーマンステストいつやる??Shuichi Takaku
600 views14 Folien
0から学んだポストモダンPerl @ YAPC::Asia Tokyo 2013 von
0から学んだポストモダンPerl @ YAPC::Asia Tokyo 20130から学んだポストモダンPerl @ YAPC::Asia Tokyo 2013
0から学んだポストモダンPerl @ YAPC::Asia Tokyo 2013Tasuku Suenaga
8.3K views113 Folien
これができたらエンジニア|YAPC::Asia 2015 LT rejected von
これができたらエンジニア|YAPC::Asia 2015 LT rejectedこれができたらエンジニア|YAPC::Asia 2015 LT rejected
これができたらエンジニア|YAPC::Asia 2015 LT rejectedTakahiro YAMAGUCHI
901 views21 Folien
Dev love関西 レガシーコードへの取り組み 20140325 von
Dev love関西 レガシーコードへの取り組み 20140325Dev love関西 レガシーコードへの取り組み 20140325
Dev love関西 レガシーコードへの取り組み 20140325Seiichi Sugahara
1.5K views63 Folien

Similar a テストコードの DRY と DAMP(20)

とある Perl Monger の働き方 von Yusuke Wada
とある Perl Monger の働き方とある Perl Monger の働き方
とある Perl Monger の働き方
Yusuke Wada15.5K views
ひよこテスト駆動開発(PHPカンファレンス2014) von Oonishi Keitarou
ひよこテスト駆動開発(PHPカンファレンス2014)ひよこテスト駆動開発(PHPカンファレンス2014)
ひよこテスト駆動開発(PHPカンファレンス2014)
Oonishi Keitarou4.2K views
パフォーマンステストいつやる?? von Shuichi Takaku
パフォーマンステストいつやる??パフォーマンステストいつやる??
パフォーマンステストいつやる??
Shuichi Takaku600 views
0から学んだポストモダンPerl @ YAPC::Asia Tokyo 2013 von Tasuku Suenaga
0から学んだポストモダンPerl @ YAPC::Asia Tokyo 20130から学んだポストモダンPerl @ YAPC::Asia Tokyo 2013
0から学んだポストモダンPerl @ YAPC::Asia Tokyo 2013
Tasuku Suenaga8.3K views
これができたらエンジニア|YAPC::Asia 2015 LT rejected von Takahiro YAMAGUCHI
これができたらエンジニア|YAPC::Asia 2015 LT rejectedこれができたらエンジニア|YAPC::Asia 2015 LT rejected
これができたらエンジニア|YAPC::Asia 2015 LT rejected
Takahiro YAMAGUCHI901 views
Dev love関西 レガシーコードへの取り組み 20140325 von Seiichi Sugahara
Dev love関西 レガシーコードへの取り組み 20140325Dev love関西 レガシーコードへの取り組み 20140325
Dev love関西 レガシーコードへの取り組み 20140325
Seiichi Sugahara1.5K views
実務でGo使い始めました von Yuki Kikuchi
実務でGo使い始めました実務でGo使い始めました
実務でGo使い始めました
Yuki Kikuchi29 views
Dockerを使ってローカルテストを良い感じに実装した話 von Ryo Yamaoka
Dockerを使ってローカルテストを良い感じに実装した話Dockerを使ってローカルテストを良い感じに実装した話
Dockerを使ってローカルテストを良い感じに実装した話
Ryo Yamaoka1.3K views
テスト駆動開発入門 - C4K Meetup#2 von Masashi Shibata
テスト駆動開発入門 - C4K Meetup#2テスト駆動開発入門 - C4K Meetup#2
テスト駆動開発入門 - C4K Meetup#2
Masashi Shibata532 views
ペアプロはリモートでもできる! von Tatsuya Deguchi
ペアプロはリモートでもできる!ペアプロはリモートでもできる!
ペアプロはリモートでもできる!
Tatsuya Deguchi4.3K views
自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips von Shou Takenaka
自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
自社開発プロダクト ALL-IN で行っている単体テストのパフォーマンスチューニングTips
Shou Takenaka4K views
bottleで始めるWEBアプリの最初の一歩 von Satoshi Yamada
bottleで始めるWEBアプリの最初の一歩bottleで始めるWEBアプリの最初の一歩
bottleで始めるWEBアプリの最初の一歩
Satoshi Yamada16.1K views
20130603 aspnet勉強会 実践的debugging von kumake
20130603 aspnet勉強会 実践的debugging20130603 aspnet勉強会 実践的debugging
20130603 aspnet勉強会 実践的debugging
kumake 1.3K views
大規模Perl初心者研修を支える技術 von Daisuke Tamada
大規模Perl初心者研修を支える技術大規模Perl初心者研修を支える技術
大規模Perl初心者研修を支える技術
Daisuke Tamada78.4K views
20120702勉強会 webアプリ作ってみた von Shugo Numano
20120702勉強会 webアプリ作ってみた20120702勉強会 webアプリ作ってみた
20120702勉強会 webアプリ作ってみた
Shugo Numano1.3K views
Aizu.LT16 社会人1年目の失敗とContinuous Integration von Tomoaki Tamura
Aizu.LT16 社会人1年目の失敗とContinuous IntegrationAizu.LT16 社会人1年目の失敗とContinuous Integration
Aizu.LT16 社会人1年目の失敗とContinuous Integration
Tomoaki Tamura1K views
非同期プログラミング養成ギブスとしてのNode.js von Tajima Itsuro
非同期プログラミング養成ギブスとしてのNode.js非同期プログラミング養成ギブスとしてのNode.js
非同期プログラミング養成ギブスとしてのNode.js
Tajima Itsuro5K views
LT: 今日帰ってすぐに始められるPython #nds45 von civic Sasaki
LT: 今日帰ってすぐに始められるPython #nds45LT: 今日帰ってすぐに始められるPython #nds45
LT: 今日帰ってすぐに始められるPython #nds45
civic Sasaki2.2K views
nseg第5回勉強会 von ko ty
nseg第5回勉強会nseg第5回勉強会
nseg第5回勉強会
ko ty798 views

Último

今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20... von
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...NTT DATA Technology & Innovation
132 views42 Folien
定例会スライド_キャチs 公開用.pdf von
定例会スライド_キャチs 公開用.pdf定例会スライド_キャチs 公開用.pdf
定例会スライド_キャチs 公開用.pdfKeio Robotics Association
127 views64 Folien
The Things Stack説明資料 by The Things Industries von
The Things Stack説明資料 by The Things IndustriesThe Things Stack説明資料 by The Things Industries
The Things Stack説明資料 by The Things IndustriesCRI Japan, Inc.
73 views29 Folien
光コラボは契約してはいけない von
光コラボは契約してはいけない光コラボは契約してはいけない
光コラボは契約してはいけないTakuya Matsunaga
24 views17 Folien
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向 von
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向Hitachi, Ltd. OSS Solution Center.
85 views26 Folien

Último(10)

今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20... von NTT DATA Technology & Innovation
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
The Things Stack説明資料 by The Things Industries von CRI Japan, Inc.
The Things Stack説明資料 by The Things IndustriesThe Things Stack説明資料 by The Things Industries
The Things Stack説明資料 by The Things Industries
CRI Japan, Inc.73 views
光コラボは契約してはいけない von Takuya Matsunaga
光コラボは契約してはいけない光コラボは契約してはいけない
光コラボは契約してはいけない
Takuya Matsunaga24 views
Windows 11 information that can be used at the development site von Atomu Hidaka
Windows 11 information that can be used at the development siteWindows 11 information that can be used at the development site
Windows 11 information that can be used at the development site
Atomu Hidaka89 views
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料) von NTT DATA Technology & Innovation
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
速習! PostgreSQL専用HAソフトウェア: Patroni(PostgreSQL Conference Japan 2023 発表資料)
SNMPセキュリティ超入門 von mkoda
SNMPセキュリティ超入門SNMPセキュリティ超入門
SNMPセキュリティ超入門
mkoda420 views
SSH応用編_20231129.pdf von icebreaker4
SSH応用編_20231129.pdfSSH応用編_20231129.pdf
SSH応用編_20231129.pdf
icebreaker4366 views

テストコードの DRY と DAMP

  • 2. 誰? • 加賀田 裕介 @_heartyfluid • 今は Web アプリエンジニア • 今は不動産とか IoT とかの会社に勤務 • 直近では自社サービスのひとつを PHP7 + CakePHP3 から PHP8 + CakePHP4 にひとりで移行作業中 • 最近の趣味はドイツ語
  • 3. ここまでのあらすじ: 気がついたらユニットテストおじさんに • 転職 • そこには前任者が書き残した壊れたユニットテストが • 自分の作業用にテストを書き足す • 自分のテスト結果が見づらくなるので、壊れたテストも直す • 「なんか今度の新入りはテストに強いらしい」 • 職場でいわゆる「ユニットテストおじさん」の地位を確立 • .oO(業務でテスト書くの初めてなんですけどね… • あわててテスト芸を仕込む日々
  • 7. 歯切れの悪い In My Opinion 「わかります。おっしゃりたいことはよくわかります。まともな神経のプロ グラマーなら、同じ文字列リテラルを2回書くなんて生理的に受け付けないで すよね。”Don’t Repeat Yourself” すなわち DRY 原則というやつですよね知ってます。でもちょっと立ち止 まって考えたいんですけどいいですか、同じリテラルを 2回書かないのってたとえば「その値を変更したくなったとき に同じ変更を2箇所に施さないといけないのはだるいから」だったりするじゃ ないですか、でもね、このテストってパス /users/add に HTTP リクエストを 投げてみるというのがそもそもの趣旨なわけでしょう、そうすると文字列リ テラル ‘/users/add’ を変更したくなるケースって実はそんなに想定しなくても いいと思うんですよ。えっいや100%保証できるわけじゃないですけど…でも まあそうだとするとですよ、その行でどんな値になっているかその1行を読ん だだけではわからない変数よりも、値をベタッと書いてあるほうが読み手に は読みやすいんじゃないかなあと思うんですよね。えっ大差ない?お前だ け?気合いの問題?ええっと…(続
  • 9. もうひとつの原則:DAMP • DAMP; Descriptive And 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 っていまいち必要性がわからないことないですか。ドイツ語文法の「再帰 動詞」を学ぶとより立体的に理解できます(※個人の感想です)。ドイツ語はいいぞ

Hinweis der Redaktion

  1. 0:05
  2. 0:20
  3. 0:35
  4. 1:00 1:10 1:20
  5. 1:35 1:45 ただ、非常にためらいもある
  6. 2:00
  7. 2:15
  8. 2:20
  9. 2:50 3:10 3:20
  10. 4:10 4:30