「早期リリースが頻繁にリリースされる」環境での単体テストの関連性は何ですか？

過去1年ほどの間、私はチームをリリース-アーリー-リリース-頻繁な開発モード（別名：アジャイルではなく迅速なアプリケーション開発）に向けました。ビルドを閉じる方法の詳細については、こちらの回答を参照してください 。RAD環境でのリリース品質を向上させる簡単な方法

私たちがRADを採用したとき、人々は非常に独立していて、最初にユニットテストを行っていました。統合テストはプロセスのかなり後の方で行われました。それは、正式な強制をあまり行わなかった彼らにとって自然なプロセスでした。今の状況はかなり異なります：

1. プラットフォーム全体は、ホットスポットがなく、クライアント側で機能する確立されたビルド/リリースとうまく統合されています。

2. 新しい機能の要件は今後も続き、必要に応じて段階的に構築していきます。

3. 独立した開発グループがプロセスを正しくフォローしている一方で、複雑で自明ではない状況が原因で重大な障害が発生しているため、システムの全体的なダイナミクスは非常に重要です。

4. システムの多くの部分には新しいアルゴリズムと研究入力が含まれるため、明確に定義されたソフトウェアでの機能テストのように、課題（およびテストのメカニズム）が常に正しく予測されるとは限りません。

最近、プロセスの改善が必要かどうかを確認するために、全体像をよりよく把握することを試みていました。チームと一緒に座ったとき、彼らの多くは「私たちはもうユニットテストをしません！」他の人たちは、効果がなくなるので今すぐ始めるべきではないと考えました。

単体テストは比較的成熟したシステムで役立ちますか？ユニットの成熟度に応じて、少なくともテストスコープの重量を量る必要がありますか？単体テストは開発のペースを遅くしますか？単体テストを別の方法で評価する必要はありますか？

リリース早期リリースの環境で成熟したプラットフォームをテストするためのベストプラクティスは何ですか？

単体テストは、主に最初にバグを見つけるためのものではありません。システムの次のリリースが前のリリースと同じくらい安定していることを確認するためのものです。リリースサイクルが短いほど、このテストを手動で実行する代わりに自動的に実行できることがますます重要になります。

もちろん、いくつかの独立した部分を持つシステムがあり、システムのごく一部でのみ2つのリリース間で作業していた場合、システムの他の部分に対する一部の単体テストを省略することができます。ただし、作業している部分のユニットテストは必ず使用（および拡張）する必要があります。

もう1つは、システムが成長すると、追加の統合テストの必要性がますます高くなることですが、それは、必要な単体テストの数が少なくなるという意味ではありません。

あなたの背後にある本当の質問は、おそらく別の質問かもしれません。システムがどんどん大きくなっているので、単体テストを書くのが難しくなっていますか？あなたの「単体」テストは本当に単体テストですか、それとももはや単独で物事をテストしていませんか？これは、時間の経過とともに安定したシステムの下位レベルの部分に依存しているためと考えられます。

これらは、開発者が既存のライブラリとコードを直接参照して再利用する傾向があるために起こります。ユニットテストはより複雑な環境とより多くのテストデータを提供する必要があるため、単体テストの記述が難しくなることがよくあります。それが問題である場合は、重要な概念であるDependency InjectionおよびInterface Segregation Principleについて学習する必要があります。これは、コードをよりユニットテスト可能にするのに役立つ場合があります。

テストが最初に設計されるテスト駆動開発を検討することを検討し、新しいコードが記述されたときにどのように機能するかを説明する必要があります。次に、テストに合格します。

私の経験では、これにより、特にライブラリのコードをより無駄のない優れたものにする傾向があり、これは仕様の実行可能な部分です（つまり、常に正しいドキュメントになることを意味します）。

ただし、既存のテストは、コードが期待どおりに機能することを確認するために使用されます。コードの破損を検出し、アップグレード時にサードパーティのコードが期待どおりに機能することを確認できます。

Doc BrownとThorbjørnRavn Andersenが示唆しているように、Releaseの早期リリース環境は、長いリリースサイクルを持つものよりも、優れた単体テストとテスト駆動型開発からさらに多くの恩恵を受けることができます。

適切な継続的インテグレーションシステムがあり、機能を適切に表すテストがある場合、何が機能しているか（その機能のテストが成功しているため）、まだ実装されていないもの（その機能のテストがないため）。