私たちのソリューションは最終的には大企業になるため、統合テストの数は増えるでしょう (現時点では少ないですが)。ほぼ継続的な展開を目指しています (コミットとリリースの間に 2 日間)。
MyProj.Tests.Unit にはユニット テストがあり、MyProj.Tests.Integration には統合テストがあります。単体テストには TFS クラウドの継続的統合を使用し、統合テストにはダミー環境を実行する特別なビルドを使用します。単体テストと統合テストの間の分割はここでは問題ではありません。問題は、統合テストを分割する利点です。
私たちにとって、統合テストは、DB やテスト Web サービスなどの外部リソースを必要とするものです。TestCategory を使用して、次のような必要なリソースによってテストをマークするかどうかを決定しようとしています。
[TestCategory("NeedsDB")]
また
[TestCategory("NeedsServiceX")]
現在の統合テスト環境は高速ですが、プロジェクトの初期段階であるため、大きな負荷はかかっていません。一部の開発者は、属性によってメソッドが必要とするものを確認することが有用であると述べていますが、手動で更新する必要がある属性に依存するよりも、開発者が目と頭脳を使用することを好みます。
私は、この方法でテストをマークアップすることがボイラープレートYAGNIであるかどうかを判断しようとしています。
- 統合テストを今すぐ分割しないと、将来問題が発生する可能性はありますか?
- このように TestCategory 属性を悪用しているのでしょうか? それは何か他のことを意味していますか？