Brian / Chris,
I think there is no problem in use BDD's ways of thinking and
strutucture the ideas for any kind of test...
For instance, I am using Bdd sentences to write business rules, that
will be implemented by Drools or some Manager class later... I wont
automate it for now, but just fit on the "When Then" way used by
drools.... and lots of other process tools...
Well, but such low level detail test that Chris is trying to do is more
apropriated using the right tool. And in my opinion mockito is the best
approch for that.
I've used Jbehave just to handle the "black box" tests... that my
business customer can understand...
Take a look at the example in this javadoc :
http://mockito.googlecode.com/svn/tags/1.8.0/javadoc/org/mockito/BDDMockito.html
Bdd is used to comment the steps...
cheers
[email protected] escreveu:
That is exactly what I am trying to. There is no reason why BDD can not be
applied on the unit level of development. Proper TDD is actually really
about behaviour anyway. :)
Chris / Christiano,
Yes - this feels like doing TDD/unit testing via Given/When/Then
and that might not be the most appropriate use of BDD.
You could do the expects as additional @Givens
@Given a service object and DAO object
@Given the DAO object expects methodX and returns Y
@When the service method is called
The @When could do all the replays and then invoke the method.
Brian
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
