Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I'm planning to test some business rules, a pretty common task, but I'm trying to become more open to behavior specification rather than state validation these days and am trying to approach it a little differently...
With the new rule subsystem and class based rules, I would have expected this to be quite easy to approach - just mock out the rule class, stub a few things, and voila. And while this almost seems to be the case, I run into the RuleContext arguement for Execute... If this arguement were to be an interface it would make much more sense to me in order to aid things like mocking csla rule classes.Can't assign expectations on the RuleContext arguement.
I can think of a couple wacky things I could do, like create a method on my rule class that does nothing more than call a method on a RuleContext and then mock that out. But that seems very hokey.
Am I crazy or am I right in thinking that the BusinessRule class does not lend itself well to behavior specification? Do most people just do state validation like I've always done in the past? I'm just interested to know what others think on this. Thanks for any input.
BTW, I'm using Rhino mocks.
Hi,
Take a look at Samples\Net\cs\RuleTutorial solution and the approach that this shows for unit tests.
No need for mocking - just test the Rule Class do what it should and write tests in a similar way no matter if the rule is sync or async.
Jonny Bekkum, Norway CslaContrib Coordinator
Cool, thanks for the help JonnyBee, you always have pointed me in the right direction. I'll check it out!
I wrote a blog post on unit testing business rules, available here:
http://jonnybekkum.wordpress.com/2012/04/29/unit-test-csla-4-businessrules/
Hope this provide some insight to unit testing.