This topic was presented on Japan LabVIEW User Conference #2. I introduced why TDD, how does it improve our development process. I developed FizzBuzz with TDD way in live.

1. Test Driven Development in LabVIEW
~ TDDとJKI Carayaの紹介 ~
Yusuke Tochigi @ JLabCon#2

2. 2
こんかいのおはなし
LabVIEW界はもちろん、ソフトウェア開発界隈で話題の、
Test Driven Development (TDD)
について、ハンズオンを交えてお話しします。
みなさんに
- テスト駆動は素晴らしいことをお伝えしたい
- JKI Carayaを紹介したい

3. 3
こんな経験ありませんか
コードがきちんと動くかは、
最後になってみないとわからない リファクタしたら、
動作がおかしくなった
テストコードはない 入力が違うと、
予期せぬ動作となった

4. 4
こんな経験ありませんか
コードがきちんと動くかは、
最後になってみないとわからない リファクタしたら、
動作がおかしくなった
テストコードはない 入力が違うと、
予期せぬ動作となった
不具合原因、追いにくくない？
リファクタとはいったい。。。
誰がその正しさを証明するの？
仕様を理解せずに開発してない？

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ステップが真理じゃよ

8. 8
JKI Caraya
a
http://sine.ni.com/nips/cds/view/p/lang/en/nid/215909

9. 9
JKI Caraya
a

10. 10
JKI Carayaの基本
1. テストグループを定義する (Define Test.vi)
2. テストを定義する (Assert.vi)
3. エラー表示器を作成する (自動エラー処理対策)

11. 11
Interactive Window

12. 12
レポート生成
Test Suiteによるレポート生成が可能 (テキストまたはJUnit形式)

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をあきらめた方がマシ
個人の意見を述べています (;'∀')

18. 18
TDD is dead.
https://dhh.dk/2014/tdd-is-dead-long-live-testing.html
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