テストのジレンマ

第11章.テスト
自分のコードは自分でテストする必要があります.考える必要のない当たり前のことです.
もちろん説明する必要もありません.
品質はそのために大きな代価を払うことを望んでいる人だけに無料です.
これは『Peppleware』の一言です.心血を注いでも、人間は間違いを犯す.次は私の今日のミスです.

// X나 구린 코드
if (value == null) {
    throw new NotFoundException();
}

// 끝내주는 코드
Optional.of(value).orElseThrow(() -> new NotFoundException());

Javaをよく使う人は、上のコードがNPEを生み出すことを知っているはずです.(私は最近Javaをやり直しています…)

// 의도한대로 동작하는 진짜 끝내주는 코드
Optional.ofNullable(value).orElseThrow(() -> new NotFoundException());

なぜofとofNullableを詳しく区別しなければならないのか分かりませんが、Javaに触れたばかりで間もなく、よくやったと勘違いしてQAにテストを渡して、漏れやすいです.しかし、これはテスト環境に導入され、QAがテスト時に発見すべきレベルのコードですか?2つのユニットテストで検証できます.valueがValueクラスオブジェクトの場合nullです.はっきりしている.
もっと努力して仕事をしたいより、もっと賢く仕事をしたほうがいい.
テストコードの作成は効率的ではないと考えられていた.皮肉なことに、当時コンパイルプロセスのないRuby on Railsを開発していた.理解できない既存のエラーテストケースに疲れ果てた.「Unitテストをあきらめて集中して編みましょう」実際に開発が加速したと思います.しかし、これは私自身の物語です(しかし、本当にそうですか?私は自分に疑問を持っています.)私の考えに共感しなかった開発者は、テストなしで以前と同じように開発を行いました.開発プロセスは効果的に変更されましたか?私の考えが賢明かどうか考えてみます.
良好なテスト特性-特殊な機械設定を必要としない
テストは、1つのアプリケーションのみを完全に実行する必要があります.DBやCacheなどに対しては、必ずMockingポリシーが必要です.これにはもう一つの重要な原因がある.単一インスタンス・サービスを使用するアプリケーション・トラフィックが増加するため、マルチインスタンス・サービスを使用する必要がある場合を考慮します.以前に使用したキャッシュポリシーがローカルディスクの場合は、reddisまたは他のキャッシュサーバに変換する必要があります.(インスタンス間のキャッシュプールが一致しないため、クライアントが表示するデータが歪んでしまいます.)既存のコードがローカルキャッシュに依存している場合は、すべての既存のコードを変更する必要があります.ただし、キャッシュ・クラスがあり、そのクラスをREDISキャッシュ・クラスに置き換えて埋め込むことができますか?既存のコードを変更することなく、既存のローカルキャッシュクラスを注入する場所で置き換えるだけで、新しいキャッシュクラスを実現できます.すなわち,テストを行う際には,オブジェクト指向の原則の一つであるOCPを遵守することができる.特に最近のMSA環境では、真似がもっと重要だと思います.
悪いテストフィーチャー-ホワイトボックステスト
内部実装を理解してテストすることもできます.すなわち,内部実装が変更されると,すべてのテストコードを修正する必要がある.先のローカルキャッシュをREDISキャッシュに変更する例です.クライアントでローカルキャッシュを使用するか、REDISを使用するかは、ゲートウェイキャッシュを使用することとどのような関係がありますか?テストは入力と出力だけでいいです.
実装コードと同様に、テストコードをよくチェックしてください.
これは、テストコードを記述できるコードが重要です.もちろん重要です.そして、注意して見てください.