Hi. Have you since come to a conclusion on this? I have a similar question. I take it another example would be: Given I am on the products page. I presume it would require the running of all steps to get to that state e.g. log in and navigate to the products page. In which case the scenario could in fact read Given I am on the log in page / And I log in with valid credentials / And I navigate to the products page. So basically our starting point is always the log in page. This feels wrong but...
–
Mark ChidlowFeb 3 '12 at 11:52

2 Answers
2

The answer depends on what you are trying to test. The example sounds like something out of cucumber, but you used the term BDD. I associate BDD with bottom-up unit testing. If that is the case, lets assume you have an authentication class of some sort, and a user class.

With these classes, I would try to test the behavior (using NUnit and MOQ) of the UserActions class in regards to logging in and logging out. In this example, no work is done, but for the sake of example, imagine a fuller implementation:

I don't actually login, or logout. What I do is leverage the interface to provide canned responses that show how the class behaves when it interacts with the classes that it consumes. In this case its the authenticator and user objects. Notice that I didn't mock the user class, because, at this point, there is no need.

I'm sure other people will disagree with this approach, but this is what I currently do. It works well for me in the sense that it allows for bottom-up testing, solid code coverage, and separation concerns with my class design.

In an RSpec style syntax, which is what I think of when you say "a BDD" test, the "given" would be part of a "describe" or "context" block which is responsible for getting the tested components into the correct state and not responsible for making any assertions or verifying the behavior of the component in that state.

The "given" would do the work of setting up your component and be followed by an "it" or "should" which verifies some behavior.

describe ClassUnderTest do
describe "some feature" do
context "given that I am logged in" do
before do
sign_in Factory :user
end
it "has some behavior" do
#make some assertion about the ClassUnderTest's behavior
end
end
end
end