t_wの輪郭

定例会議中に自動テストのデモンストレーションのために、「ほらここをこう書き換えるとバグとして検知されるんですよ」ってやったら、ほんとにバグとして検知されて感動した。完璧にテストが機能しているし、カバレッジも高まってきているのを感じる。

事前準備もなく、流れで適当にコードを書き換えてバグらせたし、それでバグが検知されるだろうという確信があった。この「バグが検知されるだろうという確信」があることに対しても感動している。

何もヒットしない検索結果画面を表示したくて、
ああああああああ
と適当に入力して検索したら、
ああああああああがヒットした。
ざけんな！って思った。

自動テストとかで一意な何かがほしいとき、UUIDを生成することがよくある。テスト用のSQLiteのDBファイルの名前とか。
というのをなんとなく想起した。

偽陰性（false-negative）は、検査対象が陽性であるにも関わらず、検査では陰性だと判定され、陽性だと判定されない状態を指す。

自動テストの文脈では、テスト対象の実装に不具合があるにも関わらず、テストケースが成功する状態を指す。すなわち、テストケースがテスト対象の不具合を検出できない状態となっている。

欠陥挿入とは、自動テストのテストケースが正常に動作しているかを検査するために、テスト対象のシステムのコードを一時的に書き換えて、テストケースをわざと失敗させること。これによってテストケースの偽陰性を発見できる。

テストへの信頼の喪失が起こると、エンジニアはテストの失敗に反応することをやめ、テストスイートの提供する価値が全部削がれてしまう

信頼不能性が1%に接近すると、テストは価値を失い始める

https://logmi.jp/tech/articles/329183

Flaky Testは検査結果が陰性と偽陽性の間を確率的に変化するテストケース。

Flaky Testは以下の点においてシステム開発に悪影響を与える。

• Flaky Testを通過するために再検査が必要と成るため、自動テストの時間を押し伸ばす要因となる
• 開発者が自動テストのテストケース群を信用しなくなり、自動テストのテストケースを保守する意欲を失わせる
• テストケースの失敗が偽陽性と真陽性のどちらなのかの区別が付きづらく、真陽性を取りこぼす可能性が上がり、本番環境に不具合があるコードを配備する可能性が高くなる

テストケースに関わる機材・コンポーネント・モジュール・システムの数が増えるほど、そのテストケースがFlaky Testになる傾向がある。

全体のテストスイートの1%程度になるにつれて、開発者がテストの失敗に反応しなくなると言われている。

偽陽性（false-positive）は、本当は検査対象が陽性ではないが、検査では陽性だと判定される状態を指す。

自動テストの文脈では、テスト対象の実装に問題が無いにも関わらず、テストケースが失敗する状態を指す。また、検査結果が陰性と偽陽性の間を確率的に変化するテストケースは、Flaky Testと呼ばれる。

VRT(Visual Regression Testing)は、システムの画面上の見た目の変化を検査する、自動テストの一種。

VRTを行うテストケースは、壊れやすく、偽陽性率が高い傾向がある。

xUnit Test Patterns

『Testable Lambda: Working Effectively with Legacy Lambda』

https://blog.kuniwak.com/entry/2020/05/28/101543

Property Based Testing

https://swet.dena.com/entry/2023/11/13/170000

会社でシステムの改修にたいして、Backlogのチケット単位での試験のエビデンスが必要になったので、どうしてやろうかとなってる。

せっかく自動テストやっとるので、自動テストやってる箇所についてはエビデンスもいい感じに生成されて欲しい。

jestで差分テストやって、その結果をチケットにコピペでぺってはったるのが一番素朴な感じ。

Githubでプルリク作ったらJestが走って、プルリクのコメントでJestの実行結果のレポート出るみたいな感じにしたいっすね。

JestのHTML reporter色々あるけど、定番とか無さげ？jest-junitがJestの公式で言及されてるけど、出力がXMLなので扱いがめんどい。

作っているシステムがなかなか品証を通らずリリースできないでいる。

品証が通らなければリリースを翌週に延期してバクを直すのだが、時間が余って機能追加するものだからそれでまたバグるみたいなことを繰り返している。

自動テストを作ってもコレなので、システムの規模が大きくなると厄介だ。

なんとか今日中にバグを直して、品質保証して、翌週月曜日にリリースできるようにしたいけども、今日は午後から社員旅行で時間がなくて無理そう。

バグ直すだけならできると思うんだけど、自動テストの拡充チャンスなので、自動テスト化してから直したい。

CypressによるE2Eテストもgit commitの度に実行されるようにしてあったのだが、これはやめてしまった。リリース時のみ使用することとした。

まず時間がかかりすぎる。1ケースあたり1秒はかかる。複雑なことをすれば10秒20秒かかるのが当たり前になる。現時点で20のテストケースが作られており、全て実行されるまでトイレに行く時間程度はかかる。

次にAWS費用が高くついた。E2Eテストなので当然APIが叩かれ、DBにクエリが走り、ログが保存される。1日に15回ほどのgit commitをしたところ、その日のCloudWatchの費用がX USDを超え、予算超過のアラートが出た。E2Eテストが今月分の予算を食い尽くしてしまった。確かに開発速度と引き換えの必要経費と言える。日給XXX円と思えば破格だ。しかし今は上司が育休に入っており予算を拡大するには予算申請が社長に飛ぶ。社長の時間単価はX USDよりはるかに高い。あとなんか怖い。予算超過は年に均せばまだセーフということで、なんとか爪に火を灯して凌ごうとなった。

しかし、このみみっちい判断が社長の意にそぐわない可能性は高い。やるべきことをやってない。XXX円のために人件費を垂れ流している。いや、そこまで考えるのは追い込み過ぎか。現時点で十二分に開発速度は速い。

React Testing libraryによって100を超えるテストケースが実装された。10秒ほどでそのすべてが実行される。

コードの保存、コミット、プッシュのたびに自動テストが実行されるようにしてある。

テスト作成になれてきている。加えて、一度テストを作成した箇所はテストの追加が容易だ。だんだんとテスト作成速度が上がってきている。

Excelに記載してるテスト項目に対して自動テストのコードを紐付けて、自動テストできてない項目は手動テストする見たいなことがしたいんだけど、良い運用方法が思いつかない。

Excelからリンクか何かでいい感じに自動テストのコードが開けるとなお良い。

自動テストの方に名前だけの空テストコード作ってやればいいかしら。そんでもって自動テストの方で色々管理する方式。

「4回のテストで自動テストはペイする」ということで、「開発中の動作確認・git commit時の動作確認・git push時の動作確認・デプロイ時の動作確認で自動テストがつかえるので、実質1サイクルで自動テストはペイする」となった。

なので「バクを直すとき」「新機能を追加するとき」「リファクタリングするとき」に関連する自動テストを作るとコスパが良い。

プロジェクトの自動テストが整ってきて嬉しい

デプロイ・git push・git commitのタイミングで自動テストが実行されるので、自動テストが腐らないぞ！

「自動テストで画面を画像として機械学習に投入して自動探索と異常検知をさせる」とか夢想するけど、計算能力的に10年後だな

遺伝的アルゴリズムにしろ、遺伝的プログラミングにしろ、与えられた課題に有利なバグがあったら徹底活用してくるし、不利なバグがあったら徹底回避してくるので、バグの発見が難しい。内部で乱数が使われているのも輪をかけてバグの発見を難しくしてくる。

なので自動テストで一個づつ動いているか確認しようと思ったのだが、ちゃんと動いてるはずだったのに自動テスト書いたらpanicで全然動かへん。

なんで動いてるんだこいつ……

いや、なんかgo runで動かすとバグんないんだけど、go testするとバグる。なんだこれ、goroutine分からん。

やっぱりgoroutineというか並列処理みたいなことを再帰関数でやるってのは辞めた方が良い予感。ワシには難しすぎる問題になる。

func node_exec(node *Node, program Program, inputs *[constant.EMBEDDING_LENGTH + 1]int, input_map *map[int]int) int {
	if node.Executed {
		return node.Value
	}
	if node.Function < program.Static_functions_index_max {
		node.Executed = true
		node.Value = program.Functions[node.Function](inputs, input_map, &program.Queue, &program.Stack, 0, 0)
		return node.Value
	}

	wg := sync.WaitGroup{}
	node.Executed = true
	arg1 := 0
	arg2 := 0
	wg.Add(2)
	go func() {
		arg1 = node_exec(&program.Nodes[node.Index1], program, inputs, input_map)
		defer wg.Done()
	}()
	go func() {
		arg2 = node_exec(&program.Nodes[node.Index2], program, inputs, input_map)
		defer wg.Done()
	}()
	wg.Wait()
	node.Value = program.Functions[node.Function](inputs, input_map, &program.Queue, &program.Stack, arg1, arg2)
	return node.Value
}

ユニットテスト始めました

毎回AWSにデプロイして動作確認しなくて良くなったので体験が良い
待ち時間が減った

退屈嫌いAIを使って自動テストとかできないだろうか。

https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition