Open hssahni opened 8 years ago
It also depends on how your rules are written. If you use InputProperties/DependentProperties/AffectedProperties and avoid direct calls to the actual BO instance it will be easier to have unit tests.
You may take a look at the Csla\Samples\NET\cs\RuleTutorial solution. There is a few projects there that shows to create unit tests for business rules and some helper classes.
Jonny is correct - if your goal is to unit test the rules, then the rules should be implemented as a rules library so the rule classes are not embedded within your business classes.
Obviously that can complicate the rule implementations, as they need to be decoupled in a more clear and obvious way, because they won't have access to the same scope as they do when they are contained within the business class, so your rules will need to rely entirely on the formal input/dependent/affected property model, and very possibly your business classes will need to implement interfaces that allow defined access to property values from an external rule.
But if you create your rules in that manner, then the rules become very testable because you can mock any interfaces the rule relies on, and your unit test can clearly define the input/dependent/affected property values it provides to the rule.
As with any code, if the code wasn't written with mocking in mind it will require updates to support that approach.
UsingCSLA4-03-DataAccess has chapters on Unit testing. Do they not serve the purpose?
I've started working on WPF application that was developed using CSLA (BusinessObjects, Data Portal, etc). Most of the Business Rules/Validation are defined in the BusinessObjects layer.
We want to use Mock to Unit Test the Business Rules, etc but finding it too hard with current implementation as everything is too tightly coupled...
Can someone point me to the right direction? Examples, Sample Code, Guidance...