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

テスト駆動開発と私 / TechBookWalk TDD

B8e501d93b98a553abf0b5cee0c33503?s=47 yasaichi
December 05, 2017

テスト駆動開発と私 / TechBookWalk TDD

技術書の歩き方勉強会「テスト駆動開発」編(2017/12/05)

B8e501d93b98a553abf0b5cee0c33503?s=128

yasaichi

December 05, 2017
Tweet

Transcript

  1. テスト駆動開発と私 Yuichi Goto (@_yasaichi) Dec 5, 2017 @ 技術書の歩き方勉強会「テスト駆動開発」編

  2. self.inspect • ピクスタ株式会社  技術推進チームリーダー • Twitter: @_yasaichi • GitHub: yasaichi

    • Blog: http://web-salad.hateblo.jp 2 他社さんにおける技術基盤の ようなチームです
  3. https://pixta.jp クリエイターと購入者をつなぐデジタル素材のマーケットプレイス 3

  4. Agenda テスト駆動開発(本)との関わり   テスト駆動開発との出会い   テスト駆動開発に対するスタンス   まとめ 4

  5. テスト駆動開発(本)との関わり • 原書(2002年)・旧訳版(2003年)ともに未読 • 原書の発売時は小学生 • 2013年のピアソンショックにより旧訳版は絶版に • 新訳版のレビュアー •

    付録C 「訳者解説:テスト駆動開発の現在」を担当 5
  6. 付録Cについて • ざっくり言うと、和田さんによる良質なサーベイ論文 • 過去: テスト駆動開発の進化と普及の歴史 • 現在: 教条主義化と意味の希薄化 •

    未来: これからのテスト駆動開発の学び方 • このためだけに本書を買ってもいいくらいの質の高さ 6
  7. 本文を読んで感じたこと • Kent Beckの思考過程を追える感覚、プライスレス • 思考過程は特定言語によらないので価値がある • ペアプロではなく書籍で伝えているのがすごい • 和田さんの訳注の質が高い

    • 古くなった記述に「今はこうです」という補足がある 7
  8. Agenda   テスト駆動開発(本)との関わり テスト駆動開発との出会い   テスト駆動開発に対するスタンス   まとめ 8

  9. テスト駆動開発との出会い • ≒ 和田さんとの出会い • 2013年、大学院生になって始めたエンジニアの
 アルバイト先(ピクスタ)で出会う • 当時の認識: 「Wikipediaに載ってるすごい人に


    技術コンサルティングをお願いしているらしい」 • しばらくは特に関わりがなかった 9 現在も引き続きお世話に なっています
  10. 初めてのペアプログラミング • 2014年の春休みに大きめのリファクタ案件を任される • それまでは小さな改善タスクだけやっていたので、 テストを書く必要がなかった • 和田さんの「RSpecの入門とその一歩先へ」を写経し、 本文中の知らない単語を調べて下準備 •

    人生初のペアプロを和田さんと行う(with RSpec) 10
  11. テストにまつわる当初の認識 • 意味の希薄化(付録C参照)したTDD/BDDそのもの • テスト駆動開発 = テストを先に書くこと? • テストの書き方にはassertionとexpectationの
 2つのスタイルがあり、RSpecは後者に属する

    • double, stub, mockの違いがよくわからない 11
  12. そして今日に至る • ペアプロを通じて和田さんに話しかけやすくなる • 曖昧な認識が議論・質問を通じて矯正されていく • DbC, DB設計, REST, キャリア設計など、テスト


    駆動開発以外のことも和田さんから学ぶ • 今回書籍のレビュアーになり、少し恩返しできた感 12 和田さんに伺った話を再現する ことを「和田芸」と呼んでいます
  13. Agenda ɹ テスト駆動開発(本)との関わり ɹ テスト駆動開発との出会い テスト駆動開発に対するスタンス   まとめ 13

  14. https://twitter.com/_yasaichi/status/936832539427094528 “テスト駆動開発は、「コードで記 述されたロジックや振る舞いを変更 する際に、フィードバックサイクル を⾼速で回すための現時点で最良の ⼿段」である” ― Yuichi Goto (

    ) 14
  15. フィードバックサイクルという観点 • テストを書く・書いてあると個人的に嬉しいケース • テストを書く→仮実装→本実装の過程で • レガシーコード改善のお供として • Railsアップグレードの際の命綱として •

    「変更の影響をすぐ知りたい」という点で目的が同じ 15
  16. 「ロジックや振る舞い」以外の場合は? • 例: コードで記述された「見た目」を変更する場合 • そもそも「どう見えるか?」をコードで記述できない • DOMやclass名などを使えば「見た目がどのように 構築されるか?」は記述できるが、壊れやすい •

    より高速なフィードバックサイクルを達成するための 別の手段があるのでは? 16
  17. https://medium.com/nulogy/storybook-driven-development-a3c517276c07 17 例えば、Storybook Driven Development (SDD)

  18. SDDの実装・テストの流れ 1. 実装対象のUIコンポーネントの状態を全て列挙し、
 Storyとして記述する 2. 各Storyで期待する見た目ができるまで、ブラウザ
 上のレンダリング結果を目視確認しつつ実装する 3. 実装がひと通り終わったら、Snapshotを作成する 4.

    以降はSnapshotを使って回帰テストを行う 18
  19. 目的を達成する手段はひとつではない • 実装の対象によって最良の手段は異なる • ロジックや振る舞い: これらのテストコードを使って 実装を進める(または変更する)TDD • UIコンポーネントの見た目: 最初は目視確認で


    実装を進め、回帰テストにSnapshotを使うSDD • 今後状況が変化すれば、また別の手段が出てくる 19
  20. Agenda ɹ テスト駆動開発(本)との関わり   テスト駆動開発との出会い   テスト駆動開発に対するスタンス まとめ 20

  21. まとめ • 新訳版「テスト駆動開発」は原書の価値+和田さんの 訳・付録により現在においても手に取る価値のある本 • テスト駆動開発に対する私のスタンス • ロジックや振る舞いを変更する際に、フィードバック サイクルを高速で回すための現時点で最良の手段 •

    銀の弾丸ではない(例: UIコンポーネントの見た目) 21
  22. ご清聴ありがとうございました 22