clear goal, achivement check, secure improvements
何を書きたいか明確にし(曖昧なテストは書けない)、その達成度を確認でき、完成後の改善における安心感を与えてくれる
red is red, check green, secure refactoring
目的
目的: ソフトウェアの目的達成を支援すること
得られるもの:
- 良い変更の増加(正常性を担保するテストの破壊検出 => regressionの回避 (安全) => 安全な変更ができるという信頼 (安心) => 変更の心理的ハードル↓ (安心))
「変更への信頼」
Wikipediaに移行
単体テスト等のtestの立ち位置
testingの一部: checking == check achivement/break in pre-defined manner
コーディング中にも書き捨てのcheckをいくつも作っている
これをtestとして整備すれば効率の良いachivement checking + その後のbreak check => refactoringが効率化できる => test-first
昔ながらのcoding:
1. declare types
2. implement function
3. test function by checking codes
4. if not work, go to #2
5. finish
1と2の間にtest (behavior check) を書く
test-firstで全部のテストを最初に書くというのも1つのやり方.
TDDは思想が違って、1歩ずつ現実化してR-G-Rを回すのが方法論.
checkingの要素
- assertion
- 結果表示 (assertion catch & display)
- その他
libraries
framework(JS/TS): JestJest: testを"する"
いちいちconsole叩くのはめんどくさすぎる
watchかエディタのショートカットが必須
https://github.com/jest-community/vscode-jest
これでwatch+各testのresult表示が無設定導入できた == 自動テスト
TDD
プロダクション含めて何度か試した結果、気が向いたら使う、くらいで私は認識している.
RED->GREEN->REFACTORING
じゃなくて
WRITE(WHITE) -> GREEN ->REFACTORING
でもいいかなーと。
小さなテスト/checkingで一歩ずつ小さな実装、は理にかなっていると思う。
REDで用途をはっきりさせる、のも理解できるけど、型設計をキメつつ(TDD-likeに)1つの機能をつけていけば、用途の曖昧さがボトルネックになることはあまり感じない (曖昧な時だけRED使う)。
WHITE -> GREENでもリグレッションテストがコツコツ積みあがって、(当然)自動テストしているのでリグレッションREDを検知できる。
TDDやtest-firstのエッセンス(段階的開発 & 変更への信頼)は2020年のエンジニアに浸透しきっていて、いい意味でTDDは古典になったと思っている。