私は財務情報 Web アプリを開発しているチームに所属しています。自動化されたテストをまだ多く書いていないため、プログラムの最も重要な部分に回帰テストを追加することにしました。ただし、私は自動テストに非常に慣れていないため、テストをどのように記述すればよいか完全にはわかりません。
この投稿は長いので、ここに tl;dr の質問があります: 特定の計算が機能しているかどうかを確認する回帰テストを作成するにはどうすればよいですか? ただし、計算をテストしたいだけではありません。また、計算が依存して入力が壊れるコンポーネントがあるかどうかも知りたいです。特にどのコンポーネントが壊れたかを知る必要はありません。何かが機能していないだけです。どのようなアプローチを使用する必要がありますか?
これが私たちの状況です。次のように、階層化されたアーキテクチャを使用してアプリを開発しました。
Views
|
V
Logic Managers <--> Financial Calculation Engines
|
V
Data Accessors
|
V
Database
計算エンジンは、回帰テスト スイートが最も必要なプログラムの一部であると判断しました。これらのコンポーネントには、生の財務データを有用な結果に処理するために使用する計算とアルゴリズムが含まれています。対応する Manager は、生の財務データをパラメーターとして受け入れる public メソッドを呼び出すことによって、それらを使用します。エンジン メソッドが戻ると、処理された財務結果を含むオブジェクトが返されます。一方、マネージャーはデータ アクセサーから生の財務データを取得し、データ アクセサーはデータベースからデータを取得します。
私たちは、財務計算が「壊れる」とすぐに知りたいと思ったので、最後のテスト実行以降にプログラムのどこかにバグがあったことがわかりました。これにより、継続的なテストを使用して、エンジンが間違った結果を生成したり、どこを見ればよいかわからなくなったりすることを防ぐことができます。
これが何を意味するのかを考えてみると、各エンジンに単体テストを追加するだけでは不十分であることがわかりました。たとえば、データ アクセサーへの誤った変更が、間違ったデータのプルを開始したことを意味するとします。このデータはマネージャを介してエンジンに送信され、間違った結果が生成されます。ただし、エンジンのアルゴリズム自体は引き続き完全に機能するため、単体テストは引き続きパスします。これは、間違った数値が生成されていることに気付いたときに、バグがいつ導入されたかを知る方法がなく、追跡と修正がより困難になることを意味します.
代わりに、間違ったデータがエンジンに送信され、エンジンに送信されることが問題であっても、エンジンが出力する最終結果が正しくないバグが発生した場合にすぐに検出できる回帰テストを作成したいと考えています。エンジン自体に問題があるわけではありません。これらのテストが失敗した場合、どこに問題があるかはわかりませんが、継続的にテストを行っている場合は、バグがチェックインされ、それを修正するためにいくつかの変更を確認するとすぐにわかります。
それが私たちがやりたいことです。残念ながら、これらのテストの作成方法はわかりません。これらのタイプの回帰テストを作成するには、どのようなアプローチまたはパターンが役立ちますか?