始めようテスト駆動開発

部会用発表資料

Transcript

1. 始めようテスト駆動開発 2016/11/11 システム開発グループ会
2. ◦◦駆動開発 1. TDD 2. BDD 3. TiDD 4. FDD 5. DDD 6. UCDD 7. AlcDD
3. ◦◦駆動開発 1. TDD( テスト駆動開発 ) 2. BDD （振舞い駆動開発） 3. TiDD （チケット駆動開発） 4. FDD （ユーザー機能駆動開発） 5. DDD( ドメイン駆動開発 ) 6. UCDD （ユースケース駆動開発） 7. AlcDD （アルコール駆動開発） ←　今日はテスト駆動開発のお話です
4. ところで皆さん、◦◦を実装してくださいっ て言われたらまず何をしますか？
5. １，とりあえず実装から入るタイプ 「いいから実装だ！！！」 • スピード重視の時 • ワンタイムしか使わないプログラミング （簡単な競技プログラミングとか） • つまり保守なんかしないよって人
6. ２，まずは設計から入るタイプ 「そんな設計で大丈夫か？」 • 一般的な開発スタイル • 設計書が神 • ただしその設計書は開発と共に 保守されないといけない
7. ３，テストから書いていくというあなた 既にテスト駆動開発をやられてるあなたに今回 のお話から得られるものは少ないかもしれませ ん ただし・・・
8. 本日のアジェンダ • TDD 概要 • テストの自動化について • CI と TDD について 今日話さない事 • テストコードの書き方とか
9. TDD概要 ユニットテストフレームワーク（◦◦ Unit ）等を利用し、 プログラマがソフトウェアの自動テストコードを記述・保守しながら 開発をすすめる手法の事 ※　品質保証を主目的にした技法ではない
10. TDDの役割 テストによって得られる情報を開発（主に設計と実装）に フィードバックしていく • 不安の解消 • 気づき
11. 不安の解消 テストを行う事で不安を解消し、 プログラミングの一歩一歩を確実なものとする （結果として品質の向上につながる） 不安の例 • ネストした if 文をテストしないことに対する不安 • 経験の浅いライブラリをいきなり使うことに対する不安（テストの形で書いて技術検 証を行う）
12. 気づき テストを書くと設計段階では気づかなかったことにも気づく （設計へのフィードバック） 例えば • クラス名やメソッドが変 • 使用する為の前提条件が多い • API が直感的でない
13. TDDの方法 Red,Green,Refactor のサイクルで開発を行 う事 • Red( テストが失敗する事 ) • Green( テストが成功する事 ) • Refactor( コードのファクファリング )
14. 方法（詳細） 1. 目標を考え、 TODO リスト等にまとめ、その中から行うものを一つ選択する 2. 選択した目標を示す自動テストコードを書く 3. 自動テストを実行し、２で書いたテストが失敗することを確認する (Red) 4. １で選択した目標を達成する為のコードを書く 5. 再度自動テストを実行し、２で書いたテストが成功することを確認する（ Green ） 6. 自動テストが成功する状態を保ちながら、リファクタリングを行う (Refactor) 7. 1~6 を繰り返す
15. テスト自動化について ユニットテストフレームワーク一覧 • JUnit(Java) • PHPUnit(PHP) • PyUnit(Python) • testUnit(Ruby) • Selenium(Web) 他にも色々あります https://ja.wikipedia.org/wiki/ ユニットテスト・フレームワーク一覧
16. ユニットテストFWを使わない問題点 リグレッションテストに時間がかかる 作った人だけがテスト可能 ( 各プログラマが思い思いのやり方で、テストを実施する ) ソースコードとテストコードの分離が出来ていない (main メソッド利用したテストコード )
17. ユニットテストFWを使う利点 テストの自動化がされる ソースコードの修正（リファクタリング）後の動作保証が容易になる テストコードと製品コードを切り離せる テストコードがそのままクラスの使い方の説明書（クラスの設計書になる）
18. CIについて CI(Continuous Integration) とは 継続的にビルドやテストを実施しようという、システム開発における考え方 CI ツールとは 継続的インテグレーションを実現する為のツール CI ツールを導入する事でサーバー上で自動的に結合テストや規約のチェックを行う事が できる
19. CIとTDDとGitの運用について Git の Master ブランチは常にリリースできる状態であるという前提 • 開発者は開発ブランチをリモートにプッシュすることで CI ツールがビルドを実行して 自動テスト、規約チェックを行う • CI が設定された自動テスト、規約チェックをパスしたら開発チームはソースコードをレ ビューする • 上記二点が通れば Master ブランチへマージする 自動テストが通っている事、開発チームがレビューを行っている事で品質の保証になる。
20. TDDのデメリット • 実装工数が増加する 記述するコードは増えるということ • 顧客の理解を得るのが難しい プロダクトコードとは関係ないコードの工数を予算には載せられな い
21. TDDのメリット • プログラマは安心感を得られる • 実装時にバグの混入が軽減される • テスト工数とデバックの時間の大幅な短縮化が期待できる • デグレ防げる • 設計力がつく • テストコードがそのままプロダクトの設計書になる • テストコードを Git と CI で管理していけば設計書は陳腐化しない • プロダクトコードの品質向上につながる
22. TDDのまとめ エンジニアにとってテストコードとは • 憂鬱なテストやデバックの時間を減らし てくれる存在 • プロダクトコードを読み解く地図になりえ る存在 • エンジニアに安心感を与えてくれる存在