たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

ソフトウェアテスト

clear goal, achivement check, secure improvements
何を書きたいか明確にし(曖昧なテストは書けない)、その達成度を確認でき、完成後の改善における安心感を与えてくれる
red is red, check green, secure refactoring

ソフトウェアテスト - Wikipedia

目的

目的: ソフトウェアの目的達成を支援すること
得られるもの:
- 良い変更の増加(正常性を担保するテストの破壊検出 => 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): Jest

    Jest: testを"する"

    ファイル指定、ディレクトリ指定
    バージョン変更検出
    関連ファイル
    watchモード

いちいち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は古典になったと思っている。