ApprovalTestsはレガシー コードに適しているように見えますが、問題はレガシー コードがアプリサーバーで実行され、アプリの再デプロイに 2 分以上かかることです。このため、承認テストを実行する際のフィードバック ループが原因で、あまり頻繁にテストを実行したくないのではないかと心配しています。おそらく、頻繁にテストせずにさらに多くのコードを変更することになり、おそらく「変更->テスト->失敗->元に戻す」の繰り返しパターンに陥るでしょう。
デプロイに時間がかかるレガシー コードで ApprovalTests を使用する方法についてアドバイスをくれる人はいますか? これはまさに私が対処すべきことですか、それともこのテストを間違った方法で書いていますか?
プロジェクトで何をテストしようとしていますか?
承認テストを使用してフォームをテストする場合は、アプリケーションから依存関係を分離し、コードに対してのみテストを実行できるようにする方法を考え出す必要があります。これに対する最良のアプローチは、コードの小さなチャンクを単体テスト可能なチャンクにリファクタリングすることから始めることです。そうすれば、データ ソースと依存関係からディスプレイを分離する道筋が明らかになります。
このビデオは、レガシー リファクタリングに適しています: http://www.youtube.com/watch?v=aWiwDdx_rdo (すべてを見る価値があります)
このビデオでは、データのロードをプロジェクトから切り離す良い方法を示しています: http://www.youtube.com/watch?v=5gIeJ6z82Pk
製品の作成者から回答を得ました。
したがって、「変更->テスト->失敗->元に戻す」という懸念があり、これが発生しますが、より小さく、より慎重な変更を行うことで、良い進歩を遂げることができ、失敗はルールではなく例外です。また、レガシーでは、モットーはより良いものであり、良くないものであることを忘れないでください。アプリサーバーを必要としないテストを取得するのに十分なリファクタリングを行うまで、このテストを使用してください。その後、あなたはより速く移動します。承認テスト自体は、大きくても遅くてもかまいません。それは単なる検証です。大規模または遅いのはテストの実行です。承認テストはそのためにうまく機能しますが、それらがあなたが望む種類のテストであることを決して示唆または推奨するものではありません。
それから私は尋ねました：
「承認テストではこの方法でテストできますが、承認テストの使用方法としては適切ではありません」と言っていますか? それを正しく解釈した場合、より良いアプローチは何でしょうか?
そして彼は答えた：
はい。承認テストでは、この方法でテストできます。単体テストの良い方法ではありません。現在持っている単体テストの最良の方法である可能性が最も高いです。単体テストのより良い方法 (サーバーを必要としない方法) にリファクタリングするまで、それを使用してください。
これが同じ質問を持つ他の誰かに役立つことを願っています。