I'm wondering if people here write tests for the common rules they may add to a business object. For example, say you have a business object with these rules:
protected override void AddBusinessRules()
{
this.BusinessRules.AddRule(new Csla.Rules.CommonRules.Required(TitleProperty));
this.BusinessRules.AddRule(new Csla.Rules.CommonRules.MaxLength(DescriptionProperty, 300));
}
would you then write tests like:
var businessObject = BuisnessObject.NewBusinessObject();
Assert.IsFalse(businessObject.IsValid);
Assert.IsTrue(businessObject.BrokenRulesCollection.Contains("rule://csla.rules.commonrules.required/Title"));
businessObject.Title = "test";
Assert.IsFalse(businessObject.BrokenRulesCollection.Contains("rule://csla.rules.commonrules.required/Title"));
Or something along those lines. If you do do this, why? If you don't do this, why?
Dave
Hi Dave,
Yes, we test every business rule in our system for completeness. It's possible another developer/group of developers will make a modification and change the logistics of the rule in question.
In your example, someone could change the MaxLength rule for the Description property from 300 to 500 but not realize the implications of these changes (i.e. DB size limitation, Web Service Contract size limitation, etc...). Your automatic test scripts should catch these types of errors and warrant additional investigation.
It also provides a complete unit test case to ensure all boundary checks are still valid. 
I plan on testing my validation rules as well. Can anyone post an example of the test they are using for their CSLA objects? I've always been interested in different approaches.
Thanks!
It should be possible to directly unit test the Execute() method of a rule. You'd need to create a mock context object that exactly matches the context object CSLA provides to the rule at runtime, but otherwise this should be pretty straightforward. This is only really possible if your rule does not use the Target property and gets all its values through the input properties dictionary. This type of unit test is not a bad idea, as it directly establishes that the rule itself works.
Beyond that, you need to instantiate a business object and set the property to which the rule is attached. This is really more of an integration test, since you may obviously invoke numerous rules, and all the normal short-circuiting and priority concepts come into play.
To instantiate a business object, you may need to have a mock database, which can be done using options 2-4 of the various data portal scenarios (http://www.lhotka.net/cslanet/faq/DataFaq.ashx).
That's also true if your rule interacts with the database, which some rules do. Having that mock database capability is pretty important for any meaningful testing.
Copyright (c) Marimer LLC