0

しばらくの間、TDD/ SSRを使用しています。BDD に移行しようとしています: context、becauseOf、および Asserts。

Rhino Mocks を使用して分離していますが、現在構文に苦労しています。これが私がこれまでに得たものです（注：ContextSpecificationクラスのソース）：

public static class DocumentIdAdapterTests {
    public class DocumentIdAdapterContext : ContextSpecification {
        protected IDocumentIdAdapter _documentIdAdapter;
        protected ISettings _settingsMock;
        protected override void Context() {
            _settingsMock = MockRepository.GenerateMock<ISettings>();
            _documentIdAdapter = new DocumentIdAdapter(_settingsMock);
        }
    }

    [TestClass]
    public class when_single_document_url_is_created : DocumentIdAdapterContext {
        protected override void BecauseOf() {
            _settingsMock.Stub(x => x.DocumentServiceBaseUrl).Return("fooOutput");
            _documentIdAdapter.GetDocumentServiceSingleDocumentUrl("fooInput");
        }

        [TestMethod]
        public void the_settings_should_provide_the_document_service_base_url() {
            _settingsMock.AssertWasCalled(x => { var ignored = x.DocumentServiceBaseUrl; });
        }
    }
}

スタブはどこに設定すればよいですか? たとえば、DocumentServiceBaseUrl プロパティが返す値のスタブはどこにあるのでしょうか? 現在、BecauseOf メソッドで実行していますが、Context メソッドで実行する必要がありますか?

4

1 に答える 1

0

それは、どのコンテキストがクラスの振る舞いに影響を与えるか、そしてどのコンテキストがクラスが動作するために単に必要であるかによって異なります。

常に特定のコンテキストから開始する場合（たとえば、ドキュメントサービスは常に特定のURLに配置されている場合）、コンストラクターまたはセットアップメソッドでこれをセットアップできます。

動作に影響を与えるコンテキスト（becauseOfsと呼ぶもの）がある場合は、各コンテキストに新しいシナリオが必要になります。これは通常、シナリオを推進するものです-コンテキストの組み合わせがさまざまな結果を生み出します（アサート）。

良いBDDトリックは、さまざまなコンテキストを探すことです。「私のコードは常にそのように動作する必要がありますか？異なる結果を生み出すコンテキストはありますか？」と考えてください。これにより、コードについて知らないことを発見するための優れた会話のスターターが得られ、動作の新しい側面ごとに例（単体テスト）を提供できます。

于 2010-09-28T06:43:32.863 に答える