BDD: When/where to setup stubs?

Question

I've been using TDD/SSR for a while. I'm trying to transition to BDD: context, becauseOf, and Asserts.

I'm using Rhino Mocks to isolate, and I'm struggling with syntax now. Here's what I've got so far (note: ContextSpecification class source):

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; });
        }
    }
}

Where am I supposed to setup my stubs? For example, where am I supposed to stub the value that the DocumentServiceBaseUrl property will return? I'm doing it in my BecauseOf method now, but should I be doing it in my Context method?

Answer 1

It depends which contexts affect your class's behaviour, and which are simply necessary for your class to operate.

If you always start with particular contexts (for instance, your document service is always located at a particular URL) then you can set this up in the constructor or setup method.

If you have contexts which affect your behaviour (what you call becauseOfs) then each context will need a new scenario. This is usually what drives scenarios - combinations of contexts producing different outcomes (Asserts).

A good BDD trick is to look for different contexts. Think, "Should my code always behave that way? Is there a context which produces a different outcome?" This gives you good conversation starters for discovering anything you don't know about your code, and allows you to provide examples (Unit tests) for each new aspect of behaviour.