1. なんでもテストすれば良いと思っていた

ソフトウェアエンジニアになって自動テストを覚えてから、その便利さゆえに全てのメソッドに単体テストを実装しないといけないと思っていた。

たしかKent Beckの「テスト駆動開発」という名著の中でも、全てのメソッドをテストするんだ！てきなことを言っていた気もする(うろ覚え)。

しかしながら、実際に現場に出てみると当たり前のように時間の制約があるため全てのメソッドにテストを入れることは不可能に近いことに気が付く。

ベンチャーのように時間がない中でも本当に単体テストは全てのメソッドに対して用意すべきなのだろうか？

2. ビジネスロジックからテストせよ

この問いに対して「単体テストの考え方/使い方」(Vladimir Khorikov 著)では「ビジネスロジックからテストせよ」とのことが書かれている。

その心は、「システムに取って重要度の高いコードを優先的にテストせよ」だと思う。

言われてみれば当たり前のことだが、自動テストという便利なトンカチを持ってから、全てが釘に見えていた自分ははっとさせられた。

確かにプロダクションコードの中には、テストしなくても明らかなコードもあるし、一方でビジネスロジックのように重要度の高いコードもある。

そんな中で、時間がない中でテストを作って元が取りやすいのは明らかにビジネスロジックである。

ついでに考えるとDDDやクリーンアーキテクチャも同じようなことを言っており, ビジネスロジックに重点をおいて開発を進めようということは実装においてもテストにおいても重要なんだと思われる。

また、「単体テストの考え方/使い方」で面白かった点がもう１つある。

「単体テストも技術負債」という考え方である。

「え？単体テストがあればあるほど、リファクタリングがやりやすくなって、技術負債はなくなるんじゃないの？」と私は思ってしまったが、言われてみれば当たり前のことである。

なぜなら、テストも当然のように手入れが必要で保守の対象になるためである。

やたらめったら作った割に重要なコードをテストしているわけではないのに、保守にばかり時間がかかるという状況になってしまえば、全体としては生産性はマイナスになっているわけである。

思い当たる節がとてもある、、、

重要度の高いコードから効果的にテストすることを念頭において頑張りたい、、、、

以上