Upgrade to Pro — share decks privately, control downloads, hide ads and more …

オライリーサブスクで名著の原著に挑戦 読書シェア会 vol.4

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on. →

オライリーサブスクで名著の原著に挑戦 読書シェア会 vol.4

Avatar for akito hagio (おはぎ)

akito hagio (おはぎ)

April 28, 2025

More Decks by akito hagio (おはぎ)

Other Decks in Programming

Transcript

  1. 自己紹介 - 萩尾亮斗 (おはぎ, ohagi) - Xアカウント: akeybako - 趣味

    - 読書 - ゲーム - スポーツ観戦 - Androidエンジニア@Voicy (今年の2月から) - 音声プラットフォーム - 自分も音声発信やってます! - おはぎのたなぼたラジオ
  2. オライリーサブスクにつ いて オライリーサブスクについて • O’reilly Learning Platform • 💰月額$49、年額$499 •

    ACM会員のバンドルとして使うとちょっと安くなる • 日本語の本は比較的少ない • オライリー原著はもちろん多数、というか膨大 • オライリー以外の名著も多数読むことができる • 専用のReaderアプリ(Web・Mobile)もいい感じ こんな人におすすめ! • 英語を学びながら技術を学びたい人 • 原著ならではのニュアンスを掴みたい人 • オライリーの本をつまみ食いしたい人 • 今後和訳されるであろう名著を先読みしたい人
  3. 本の概要 • Unit Testing Principles, Practices, and Patterns ◦ 邦題:

    単体テストの考え方 /使い方 ◦ ITエンジニア本大賞 2024 ベスト10 • マニング出版より 2020年1月に出版 • サンプルコードはC#で書かれている • 構成 ◦ 全体像 ◦ テストを役立てる ◦ 結合テスト ◦ アンチパターン この本から学べること • 単体・結合テストに関する体系的な知識 • 単体テストのアンチパターン • 単体テスト可能性を踏まえた設計論 本の概要 この本から学べること
  4. なぜこの本を 読んだのか なぜこの本を読んだのか • 新しい環境に入ったが故の普遍的な不安 ◦ 変更が怖い...! ◦ 安心して変更をできる環境を作りたい •

    チームの共通言語になっている ◦ 私が入社する前に輪読会があったとのこと ◦ 「UTPPPには〜」のように意見をくれる方がいる
  5. 学び① 二つの学派 ロンドン学派 London School クラス単体をテストする 二つの学派 学ぶ前の自分の考え(ロンドン学派?) • UT:

    MockやStubを駆使した単一クラスのテスト • IT: 実際の多数のクラスを繋げて行う ロンドン学派 / London School クラス単体をテストする • テストダブル ◦ (不変なものを除いて)依存全て • メリット ◦ MockやStubを駆使することでテストしやすい 古典 or デトロイト 学派 / Classic School 振る舞いをテストする • テストダブル ◦ 共有される • メリット ◦ 非エンジニアでわかりやすい形の単位 ◦ 単体テストが難しい=設計を見直すサイン 古典 or デトロイト 学派 Classic School 単一の振る舞いをテストする
  6. 単体テストの4つの柱 学ぶ前の自分の考え • 単体テストがないことへの不安 ◦ 変更を行うことによる回帰への不安 • 単体テストそのものへの不安 ◦ なんか時間かかる

    ◦ なんか何もしてないのに壊れる 学び • この4つの柱でプラクティスを検証する • 偽陽性 ◦ 本当は壊れていないのに壊れたと言われる ◦ Resistance to refactoring • 偽陰性 ◦ 本当は壊れているのに大丈夫と言われる ◦ Protection against regressions 学び② 単体テストの4つの柱 Protection against regressions 回帰を防ぐ Resistance to refactoring リファクタリングに耐える Fast feedback 早いフィードバック Maintainability メンテナンス性
  7. 学び③ UTの3スタイル Output-based アウトプットベース y = f(x) の yが正しいか UTの3スタイル

    学ぶ前の自分の考え • アウトプットベースが一番簡単 • ケースによって使い分ける? ◦ 状態を変化させるならそれを検証する時 ◦ Mockをちゃんと呼べているかを検証する時 学び • アウトプットベースが優れている ◦ 低い偽陽性 ◦ メンテナンス性 • 実装の詳細に立ち入らないようにする ◦ ドメインロジックを凝集する ◦ 副作用のない設計(関数型 Programmingなど) State-based 状態ベース 内部状態が正しく変わっているか Communication-based コミュニケーションベース AはBに正しく依存てきているか
  8. UTPPPを 完走した感想 UTPPPを完走した感想 • もっと早く読めばよかった ◦ 単体テストについての多くの誤解 ◦ 今までの議論は空中戦だった...? •

    結構読みやすかった ◦ だいたい2週間くらい ◦ 具体的な表現が多いから? ◦ 辞書引くような単語はだいたい繰り返される • テストを書いていく上での指針ができた • Androidの場合は↓とどう付き合っていくかが肝 ◦ PureなKotlinのコード ▪ テストしやすい・大好き ◦ 外部依存(APIなど)やライブラリ ▪ 本書で言及されているようにしたい ◦ Android SDK ▪ AndroidJUnitなどのサポートが必要 ▪ 継承するだけにしちゃいがち