go の OSS でテストを書きまくったので、テストしやすくするために役立った工夫を紹介します - 若くない何かの悩み

社で必要になったので、Go 言語の OSS を書きました。 github.com この OSS がなんなのかは スライド を見ていただくとして、テストをめっちゃ書いたのでだんだんどうテストを書いたらやりやすいのかがわかってきました。この成果自体はいつか vanilla-manifesto へまとめると思いますが、簡単に説明しようと思います。 書いてて辛くないテストをするために、もっとも重要なのは テスト対象の設計 です。設計といえば、よく SOLID がよいオブジェクト指向設計の指針とされますが、テストの文脈でも同じことがあてはまります。例えば、テスト対象が SOLID をよく守っていると次のように嬉しいことがあります： 単一責任原則 (S) これが守られると、どんな振る舞いを検証したいのかが明確になるので読みやすいテストになる 開放閉鎖原則 (O) これが守られると、機能の追加/変更でテ

[devorgachem]

テストマン過激派による知見です