不毛地帯にe2eテストを書くぞ
あーFISでもapi-internal-errorとかだとdurationを指定できるので,これは一定時間エラーを出し続けることができる.難しいなぁ
あーStop conditionはあくまで中止の条件であって,終了条件ではないのか.targetにしていたものがcompleteしたらstop conditionが上がってなくても終了しちゃう
FISって終了条件がむずいな.インスタンスを殺し続けてほしい場合は単にStartするだけじゃダメなのか.現存するインスタンスを殺し終わった時点でexperimentがcompleteになってしまう.Stop conditionにcloud watch指定したらもっと長期間殺し続けてくれるかな
それはそう思う.自社サービスのスタートアップの場合,品質を上げて利益を得るのは将来の自分たちだけど,受託開発で品質を上げ続けてもそれが利益になるのか?というのは怪しい.受託の方は全然温度感わからないので,そういうのを評価してくれるところもあるのかもしれないが
秤についてはt-wadaがいつもいいこと言ってるので,このへんに全部書いてあるとして.結局短期的な機能追加は得られても,長期的には品質を下げ続けるので,成長したときに苦労しろよって話でしかない
https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition
でもマジで書かない派の人は平時に何言ってもあんまり響いてないので半分諦めている.そういう意味でも "でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。" というところは同意.書かないのではない,未熟だから書「け」ないのである
それはまぁ一人で開発してるならそうだし,別にいいんだけど,仕事で複数人でやるとなると状況はまったく逆転するよ.他人がかいたコードを確認する時間でテストコード一つ書けるよ.っていうのが人数分発生する
実際最近副業で入ったスタートアップが,全然テストがない(テストがないからCIという概念もない)んだけど,そのくせパフォーマンスが悪いからリファクタリングしてほしいと言う.リファクタリングするのにテストがないとはどういうことなのか.
PRを出すと毎回CTOが手動でpullして本番DB相当のデータを用意してポチポチいじって「ここでバグりました」みたいな報告を上げてくる.これを修正するたびにやるので,普通に1PRをマージするのに1ヶ月以上かかる.こんなのでいいのかスタートアップ?と思ってるんだけど,本人は危機感がまったくないらしく,テストを書く気もないらしい
一人ならともかく,複数人で開発するようになると,テストなしで他人のPRのレビューしてマージするのがかなり怖くなる.それをいちいち手元やdev環境用意して手動確認する暇がスタートアップにあるのか? / “「スタートアップだからテストを書かない」は正しいか - An Epic…” https://t.co/HvZV75BAjA