More Related Content
What's hot (20)
Similar to Test Driven Development in LabVIEW (20)
More from Yusuke Tochigi (16)
Recently uploaded (6)
Test Driven Development in LabVIEW
- 1. Test Driven Development in LabVIEW ~ TDDとJKI Carayaの紹介 ~ Yusuke Tochigi @ JLabCon#2
- 2. 2 こんかいのおはなし LabVIEW界はもちろん、ソフトウェア開発界隈で話題の、 Test Driven Development (TDD) について、ハンズオンを交えてお話しします。 みなさんに - テスト駆動は素晴らしいことをお伝えしたい - JKI Carayaを紹介したい
- 5. 5 TDDで開発してみなイカ？ テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) と は、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテス トを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実 装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルで ある。多くのアジャイルソフトウェア開発手法、例えばエクストリーム?プログラミングにお いて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。 By Wikipedia
- 6. 6 テスト駆動開発の教本
- 7. 7 TDDのお作法 1. 失敗するテストを書く (Red) テストを書くまでその実コードを書いてはいけない 2. とにかくテストを成功させる (Green) どんな手を使ってでも、テストが成功すればよい 3. リファクタして、テストが成功することを確認する (Refactoring) 手順2で行った悪手を反省とともに改善する Red → Green → Refactoring の3ステップが真理じゃよ
- 10. 10 JKI Carayaの基本 1. テストグループを定義する (Define Test.vi) 2. テストを定義する (Assert.vi) 3. エラー表示器を作成する (自動エラー処理対策)
- 13. 13 FizzBuzzをTDDで 1. 1から順番に数字を発言する 2. 3で割り切れるときは「Fizz」を発言 3. 5で割り切れるときは「Buzz」を発言 4. 両方で割り切れるときは「FizzBuzz」を発言 ライブコーディング このテストVIもさらにリファクタするよ！
- 14. 14 波形解析をTDDで 1. しきい値0Vを超える位置を検索する 2. “1”の位置から波形の末尾までを取得 3. “2”区間の平均値を返す ライブコーディング
- 15. 15 TDDのメリット コードがきちんと動くかは、 最後になってみないとわからない リファクタしたら、 動作がおかしくなった テストコードはない 入力が違うと、 予期せぬ動作となった 単体テストを積み重ねることで、 バグの源泉を容易にたどれる！ リファクタで不具合を発生していないことを、 ターゲットとテストが相互に保証する！ テストVIは正しさの証明！ コーディング前に仕様をきちんと確認！
- 16. 16 TDD = テスト自動化? 個人的には... 「TDDは開発思考の話なので、TDD = テスト自動化とはならない。 TDDの結果として偶然、自動化されたテストができあがる。」 (JKI Carayaにも実は自動化ツールがあるよ...) 個人の意見を述べています (;'?')
- 17. 17 TDD = 神? Q. どんな場面でもTDDで開発できますか？ A. 残念ながらUIやハードウェアAPIなどでは、TDD開発は簡単ではありません やればできるけど、無理してやるくらいならTDDをあきらめた方がマシ 個人の意見を述べています (;'?')
- 19. 19 TDDで開発すべきか？ それでもTDDで開発すると、 ● 自信をもって開発を進められる ● テストの証拠があるので発言に説得力がある ● テストパターンを意識するので、テストの抜け漏れが減る 逆にTDDが枷になったり、自分やプロジェクトに合わなければ無理して取り入れない 開発?リファクタの結果が すぐに目に見える 「だってテストしたんだもん...」 から 「テストコードがここにありまぁぁすぅぅ！」 に 開発の前に仕様書を 読まないとテストコードが書けない
- 20. 20 TDDで開発しない理由 ● 実コードとテストコードで2倍の工数かかる ● UIテストとかTDDじゃできないっしょ ● TDDのお作法に完璧に倣えない ● 評価？テスト？なにそれ？ テストしてないコードでは、後で どうせ工数増えるから今やろうぜ！ 難しければ、自分に合わなければ、 無理して採用する必要はない お作法はあるけど絶対じゃない。 分家を作ってもいいんじゃない？
- 21. 21 まとめ TDDは開発技法なので、VI Analyzerみたいに導入すると一気に何かが良くなる ものではありません... それでも適切な場所で導入すると、高品質なモジュールを開発できるので、小さなと ころでまずはトライしてみてはいかがでしょう？ 参考: Test Driven Development: A Real World Example - Sam Taggart (Automated Denver) - GDevCon#2
- 22. 22