問題タブ [bdd]

BDD仕様のリソースまたはライブラリを知っていますか？

たとえば、ほとんどすべてのWebアプリにはログインプロセスがあります。一部の「標準」機能は、パスワードを忘れた場合やパスワードをリセットした場合などです。

私はBDD仕様のコードスニペットアーカイブのようなものを考えているので、すべてを最初から作成する必要はありません。

私はasp.net mvcアプリケーションに取り組んでおり、ユニットテストBDDスタイルを書いています。例えば。

GetResource_WhenResourceFileExists_ShouldReturnResources()

しかし、コントローラーのテストを書いているときは、通常、同じ名前の 2 つのメソッドがあります。1 つは get リクエスト用のパラメーターなしで、もう 1 つは投稿用です。この 2 つを区別するための適切な命名規則を持っている人はいますか?

私は考えることができます：

ご意見はありますか？

ASP.NET MVC プロジェクトで初めて DDD を実装しようとしていますが、いくつか苦労しています。

会社とサプライヤーの 2 つの関連エンティティがあります。私が最初に考えたのは、Company は集約ルートであり、Supplier は Company の値オブジェクトであるということでした。したがって、会社用のリポジトリがあり、サプライヤー用のリポジトリはありません。

しかし、アプリの構築を開始したため、サプライヤー用に別個のリスト、作成、および更新フォームが必要になりました。Company.Suppliers を呼び出すことができるリストは簡単で、Company.Suppliers.Add(supplier) を実行できる作成はひどいものでしたが、更新は頭痛の種です。必要なエンティティは 1 つだけであり、フォーム間で正確にメモリに貼り付けることができないため、会社とすべてのサプライヤーを再取得し、それにバインドする必要があるものを見つけて、再度変更して永続化する必要がありました。デシベルに戻ります。

Supplier のリポジトリがあれば、本当に GetOne を実行する必要がありました。GetOneSupplier を Company または CompanyRepository に追加することで回避策を追加できますが、それは厄介なようです。

したがって、それが実際には値オブジェクトであり、完全なドメイン エンティティ自体ではないのではないかと考えています。

tldr;

別のリスト/作成/更新ビュー/ページが必要なのは、エンティティが独自のルートであるべきであることを示していますか?

または、基本的なエンティティの検証は仕様と見なされますか?

一般に、基本的なエンティティの検証 (名前は null または空にすることはできず、日付は xxx より大きくなければなりません) を実際のエンティティに保持するのと、仕様の外側に保持するのとではどちらがよいでしょうか?

仕様の場合、それはどのように見えますか? 各フィールドの仕様がありますか、それともすべてを 1 つの EntityIsValid 型の仕様にまとめますか?

更新： マッピングをCascade.All（）からCascade.AllDeleteOrphan（）に変更すると、ほとんどの問題が修正されるようです。それでも、OperatingStateにCompanyプロパティを明示的に設定する必要があります。これは、Companyエンティティに追加されているため不要のようですが、少なくとも更新中にはそれを使用できます。私はまだそれをcreateでテストする必要があります。

誰かがそれを説明できれば、それは大きな助けになるでしょう。

更新2：もう少し遊んだ後、親エンティティを常に指定する必要はないようです。

元の投稿

私は2つの関連するエンティティを持っています

そして、それらは次のようにマップされます。

したがって、会社を新しい運用状態で更新しようとするまでは、すべて順調です。

それは爆撃します：

列'CompanyID'、テーブル'ConsumerCartel.dbo.CompanyOperatingState'に値NULLを挿入できません。列はnullを許可しません。INSERTは失敗します。ステートメントは終了されました。

しかし、私が2つの変更を加えると、それは一種の作業になります

これにより、古い状態に加えて新しい状態が追加されますが、これは私が望んでいることではありません。ただし、会社を明示的に設定する場合でも（マップされたリストに追加するときに行う必要はありませんか？）、リストがクリアされていると機能しません。

このコードは他のエンティティでは機能しましたが、このエンティティでは機能しなかったため、これは記述どおりに機能するはずです。私は何が間違っているのですか？

Perlの単体テストとモックオブジェクトにどのフレームワークとツールをお勧めしますか？

私は既存のPerlアプリケーションを持っています。これは主にデータベースへのアクセス、ファイルの読み取りと書き込みを行います。このアプリケーションは基本的にバッチジョブタイプのアプリケーションであり、ファイルやデータベースから大量のファイルを読み取り、データベースに多数の新しいファイルやいくつかのデータを書き込みます。

現在、アプリケーションには単体テストがありませんが、アプリケーションをリファクタリングして、優れた単体テストを実行したいと思います。

オブジェクトの単体テストとモック作成にどのフレームワークとツールをお勧めしますか？たとえば、JavaのHamcrestやJMockに似たものはありますか？

また、Perl用の優れたBDD（ビヘイビア駆動開発）ベースのテストフレームワークはありますか？

多くの状況で、クラスとメソッドの適切な単体テスト名を思いつくのが困難です。通常、私は次の形式に従うようにしています。

明確にするために、Given、When、Then という単語をパーツに付ける人もいます。単体テストが何をテストしているのかをより明確にするように見えるので、私はそれが好きです。BDD ツールキットを検討する以外に、これが単純な古い xUnit ツールでどのように機能するかについてアドバイスが必要です。

次のようなシナリオでは特に苦労しています。

アプリケーションが起動すると、メイン フォームが読み込まれ、ユーザーがクリックできるリンクのリストが表示されます。

または、より良いユースケースのシナリオは次のとおりです。

ユーザーは、リンクのリストからリンクを選択できます。

確かではありませんが、アプリを実行し、フォームにクリック可能なリンクのリストが読み込まれる動作を説明しようとしています。そして、それを単体テストに変えます。

そのための与えられた、いつ、そしてその後は何ですか？

BBDはこのスレッドで参照されています（Karl Seguinの回答）。BDDとは何ですか？

インターフェイス IValidatable を実装する IEntity インターフェイスがあります。

便宜上、次のような Entity クラスを実装しました。

デフォルトでは、GetRuleViolations() または GetPersistenceRuleViolations() がオーバーライドされるまで、エンティティは有効です。

これは検証が少し単純であることを知っているので、タイプミス以外に何を改善できるでしょうか?

プロパティを持つクラス (多数) があります。ロジックがあるものとないものがあります。これらのプロパティをテストしたい場合、どうすればよいでしょうか?

最近、ユニットテストを作成するBDDスタイルに興味があります。

こことここを参照してください。

したがって、コンテキストのセットアップを行います。基本的には、SUT を作成し、必要なものをロードします。次に、各 Observation (テスト メソッド) で、特定のプロパティに含まれるべきものが含まれていることを確認します。

これが私の質問です。SUT に 20 個のプロパティがある場合、20 個の観測/テストを作成する必要がありますか? プロパティの 1 つにもっと興味深いロジックが含まれていれば、それ以上になる可能性があります。

しかし、単純なものを 1 回の観察に集約した方がよいでしょうか?

または、カスタム属性 (メソッドに複数回適用できる) を使用した場合はどうなるでしょうか。私ができるように、次のようなものです：