私はTDDの方法論全体を把握しようとしています。そのため、これを簡潔な質問として提示する方法がよくわからないため、ここに長く引き出されたバージョンがあります. ボウリング (Martin)、お金 (Feathers)、およびその他の同様のゲーム/単純な例と、完全に機能するエンタープライズ アプリとの間にギャップが生じているようです。
私が理解しているように、機能の概念のようなものが欠けているかどうかを理解しようとしています. 機能の定義が難しいルールである場合、ロギングやエラー報告などは機能ではありません。これは、TDD がログ記録と通知の手段を提供しないということですか?
戦争を始めようとしているのではなく、そうではないと確信しているので、「ビジネス価値」はアプリの途中で顧客のビジネス価値からビジネス（アプリの作成者）のビジネス価値に切り替える必要があると自分に言い聞かせます。
次に、この一般的な例のように切り替えようとします From: As a math idiot From: As a math idiot When I enter 2, press add, enter 2, then press = I want 4 returned.
宛先: システムを監視するシステム アナリストとして、ユーザーが関数を入力して未処理のエラーが発生した場合、アプリケーションの現在の状態、スローされた例外、およびスタック トレースがログに記録され、システム アナリスト配布リストに電子メールが送信されます。 .
ビジネス アナリストとして、すべての顧客注文が処理されるようにします。ユーザーが電子注文を送信し、ルーティングまたは会計情報が検証されない場合、無効な会計およびルーティング情報をログに入力し、注文ファイルを添付して電子メールで送信します。ビジネス アナリスト ユーザー グループ。ネットワークの問題が原因で顧客情報を検索するためにデータベースに到達できなかったことが問題の原因でない限り、ログに「ネットワークの問題により顧客情報を検索するためにデータベースに到達できませんでした」と入力し、エラー メッセージを記載した電子メールをシステム アナリスト配布リスト。
その後、それは完全に受け入れられないと私が思うものに拡張され始めます。電子注文完了チェックとして 注文を受け取ったときに x12 ファイルがフラット ファイルに変換されていることを確認したい。検証または変換ログに失敗した場合はエラーをメールで送信し、注文情報とステータスが抽出され、フラット ファイルがデータベースにロードされるファイルが as400 のキューに送信され、ステータスがデータベースに更新されます。 as400 が注文を受け取ったことの確認を送信し、ステータスがデータベースに更新されます。確認が x12 に変換され、ステータスがデータベースに更新されます x12 確認が適切にルーティングされ、ステータスがデータベースに更新されます 確認が送信されますx12 に無効なデータが含まれている場合、ステータスがデータベースに更新されます。エラーをログに記録し、電子メールを送信します。フラット ファイルが 2 分以内にキューから取り出されない場合は、エラーをログに記録し、x 乗の n などを含む電子メールを送信します。可能なエラー シナリオの。
それぞれを独自の「機能」に分割したとしても、アプリケーションが例外をスローしたこと、ネットワークエラーが発生したこと、データベースが見つからないことなどをシステムアナリストに通知したり、認識されないアカウント番号の注文があったことをビジネスグループに通知したりするという問題がまだあります。これらのいずれかをメソッド、属性などとしてクラスに追加すると、単一責任の原則に違反しているようです。その頃、物事がぐるぐる回り始め、めまい、息切れ、動悸がする
ですから、これを明確な質問として提起する方法さえわからないほど混乱しているので、このように要約してみます。
これらのものをいつ、どこで、どのように分解して分離するかをどのように決定しますか? それらをビジネス価値を提供する最小の部分に分解すると言うのは簡単ですが、他の多くの部分なしでは 1 つの部分を持てない場合、「本当の」答えは何でしょうか? そのすべてが 1 つの付箋には収まりません。
私はより多くの本、チュートリアル、ビデオを含む回答を受け入れていますが、アジャイルとTDDの原則に準拠し、おそらく最も価値のあるこれらの種類のものを説明する現実世界のアプリケーションがおそらくあると思いますか? 確かに、私はこれに比較的慣れていませんが、Martin/Feathers/Osherove の本を読んだことがあります。三目並べ、ボーリング、素数などで多くの型を見てきましたが、ログもエラー報告もありません。その種の「現実世界」のもの。
他のことを試してみましょう。
メインフレームから ftp 経由で、サプライヤに発注する注文をリストしたファイルを取得します。このファイルは概要ファイルと呼ばれます。このファイルを 5 分ごとにチェックします。ファイルがある場合は、それを解析し、この概要ファイルにリストされているすべての注文を MQ 経由で受け取ったことを確認します。二重チェックとして、注文の存在も確認します。なぜなら、要約ファイルを受信できない場合、すべての注文を受信したことを保証できないからです。そうは言っても、次のことは私が正しい方向に向かっているように見えますか?
Feature: Check for the presence of a summary file
In order to verify all orders were sent through MQ from the mainframe
a summary file must be found to determine the expected orders.
Scenario: A summary file has not been sent
Given a summary file does not exist
When I check for the existence of a file
Then I should sleep for 5 minutes
Scenario: A summary file has been sent
Given a summary file does exist
When I check for the existence of a file
Then I should validate the summary file
Feature: Validate the summary file
In order to process a summary file
summary file must be valid
Scenario: A valid summary file exists
Given a valid summary file
When I validate the summary file
Then I should upload the order details to the order details DB.
Scenario: An invalid summary file exists
Given a invalid summary file
When I validate the summary file
Then I should log the errors encountered
And email the erroneous file to the analyst email group
要約を順序に置き換えて、もう一度繰り返します。それが私が思いついたものです。