テストコードとスピードのトレードオフ。加えてGoのAPIのテストについて。
「テスト 書くべき」って検索すると玉石混交な記事がわんさか出てくるのですが、そもそもなんでこういった議論は常に紛糾するのでしょうか？ 僕個人としては、テストコードというものへの捉え方はその現場の思想に密に依存しており、その前提を明示しないまま議論を進めると、「スピード感」「技術者の習熟度」「自社開発か否か」などの様々な変数の違いによって意見が食い違い、容易に銃弾飛び交う戦場と化す、と考えています。 そのため、この議論を始めるのは下手をするとパンドラの箱をパカっと開けて、収集つかないことになるのかなーと思っています。 僕の置かれている前提ということで、流れ弾で死にたくないのでまず僕の前提を明らかにします。 個人的な趣味趣向の話まず個人的な立場を表明しておきますが、僕は書くまでは、億劫なんだけど書き始めたら割と好きで黙々と書いていたくなるタイプです。かといって、仕様がピョンピョン変わる現場での
お固い組織に自動テストを書く文化をインストールしようとしている - Qiita
※個人の見解です。所属する組織の意見を代表するものではありません。 未整理だけど一旦投下。 なぜ自動テストなのか（見えているゴール） よい自動テストはプロダクトの健康に大きく寄与する プロダクトの健康は開発者を変更の恐ろしさから解放する よい自動テストはシステムの継続的な運用コスト削減に寄与する 今更なに言ってんの？という話だが、固い組織の現状認識は想像を絶する たくさんの壁がある 個人の壁 「自動テストなんて書いたことありません」 「妙な仕事増やさないでよ…」 組織の壁 「そもそもユニットテストなんて書いたら、大幅に工数増えるじゃん。それどうするの？そんな工数見積に載せられるわけないでしょ？」 「品質保証としてカバレッジの目標値どうすんの？ユニットテストというなら最低限C0カバレッジ100%だよね？」 「ユニットテストのテスト仕様に問題ないことは、誰がどうやって担保するの？」 「『俺も若
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
