Fit/FitNesse を選ぶ理由

Question

xUnit スタイルの統合テストの代わりに Fit/FitNesse を使用する意味は何ですか?私の意見では、これは非常に奇妙で非常に不明確な構文を持っています。

本当にプロダクトオーナーにテストを書かせるだけなのでしょうか？そうはしないでしょう！彼らにとってそれは複雑すぎます。では、なぜ誰も Fit/FitNesse をすべきなのでしょうか?

アップデート つまり、ビジネス ルールのテストのみに完全に適しているということでしょうか?

Answer 1

要は働くことだ と プログラマーではない人、多くの場合、ビジネス アプリケーションの見込みユーザーのようなまったく技術者ではない人でも、アプリケーションが何をすべきか、そしてそれをテストに移すべきかについて検討します。テストを機能させるのは彼らにとって確かに複雑すぎますが、例えば、サンプルデータを記入した表について話し合うことができるはずです。言葉。そしてすばらしいのは、従来の仕様とは異なり、自動テストによってドキュメントの更新が強制されるため、これらのドキュメントがアプリケーションとともに存在することです。

見る フィットの紹介 そして ワークフローに適合する James Shore 著を参照し、必要に応じて残りのドキュメントへのリンクをたどってください。

---

アップデート： ビジネスルールが何を意味するかによるでしょうか？;-) 非常に狭く理解する人もいます (ビジネス ルール エンジンなど) が、非常に広く理解する人もいます。

私の考えでは、Fit は、豊富な現実的な例を含むビジネス (ドメインのような) ユースケースを文書に書き留めることができるツールであり、エンドユーザーやドメイン専門家 (一部のドメイン) が理解し、検証し、議論することができます。同時に、これらの例は機械可読形式であるため、自動テストを推進するために使用できます。ドキュメントをすべて自分で作成したり、ドキュメントを作成するように要求したりする必要はありません。むしろ、それは計算と議論の産物であり、アプリケーションが何をしようとしているのかについての双方の理解の深まりを反映しています。進むにつれて例が豊富になり、より多くの特殊なケースが解決されます。

アプリケーションがどのように機能するかではなく、どのような機能を実行するかが重要です。それは機能仕様の一種です。そのため、これはかなり幅広く、実際にはモジュールごとに整理されているのではなく、使用シナリオごとに整理されています。

例から得られるテストは、ビジネスの観点から重要な側面でアプリケーションの外部動作をテストします。はい、それをビジネスルールと呼ぶかもしれません。ただし、少しひねりを加えた、ディエゴ ジャンチッチの信用スコアリングの例を見てみましょう。Fit ドキュメントの一部が 1) 属性とそのスコアのリスト、2) クライアント データの提供と結果の確認である場合、実際のビジネス ルールは次のとおりです。スコアリング テーブル (属性とそのスコア)、または各クライアントのスコアを計算するアプリケーション ロジック (スコアリング テーブルに基づく)?そしてどれがテストされるのでしょうか？

Fit/FitNesse テストは受け入れテストに適しているようです。他のテスト (クライアント、ユーザー、ドメイン専門家などとの連携を気にせず、テストを自動化したいだけの場合) は、おそらく、より伝統的な方法で作成および保守する方が簡単でしょう。xUnit は単体テストと API テストに適しています。各 Web フレームワークには、変更、ビルド、テスト、デプロイのサイクルに統合された Web アプリ/サービスのテスト用のツールが必要です。django には小さなテスト クライアントがあります。たくさんの中からお選びいただけます。

また、いつでも独自のツールを作成 (またはできれば既存のツールを微調整) して、特定の関心のある領域にテストをより適切に適合させることができます (冗談です)。

---

もう一つ一般的な考え方。多くの場合 (常にではありません!!!)、テスト、「ビジネス ルール」、その他ほとんどすべてのものを、単純で汎用的なコード部分によって解釈される、明確に定義された何らかの形式のデータにエンコードする方が良いでしょう。その後、他の方法でデータを簡単に使用できます。ドキュメントを生成し、新しいテスト フレームワークに移行し、アプリケーションを新しい環境/プログラミング言語に移植し、外部ルールや他のシステムとの適合性を確認するために使用します (想像力を働かせてください)。コードからそのような情報を引き出すのははるかに困難です。単純なハードコーディングされた単体テストまたはビジネス ルール。

Fit はテスト ケースをデータとして保存します。使用目的からして非常に特殊な形式ですが、それでもです。ドメイン固有のテストでは、単純な CSV、JSON、YAML などのさまざまな形式を使用する場合があります。

Answer 2

考え方としては、あなた (プログラマ) が Excel シートなどのわかりやすい形式を定義するということです。するとプロダクトオーナーは、業界外の人には分かりにくい情報を入力してしまうのです…。そして、PO が Fit を実行することを期待しているとおりにコードが動作することを検証するだけです。xUnit で使用される方法は、プログラマーにとって、理解しやすい、または単純な情報の入力として使用できます。xUnit テストで複数のフィールドを含む奇妙な例を多数入力する必要がある場合、読みにくくなります。

年齢、既婚/独身、子供の数、賃金、活動などに基づいて、顧客にローンを与えるかどうかを決定する必要がある場合を想像してください。プログラマはそのような情報を書くことはできません。そしてリスク管理者は xUnit テストを作成できません。

Answer 3

回帰テストやバグテストの冗長性を減らすのに役立ちます。テスト ケースの管理可能なリポジトリを構築します。一度構築すれば永久に使用できるようなものです。