I have completed the creation of my 3 sample BO objects (Meeting-->AgendaItems>AgendaItem) and they are all working well
Which leads me to REALLY want to polish the unit testing and how that should work. I read the long post from a few years on Unit Testing and that was somewhat helpful. Mostly it confirms that the way I have decided to do this is not all wrong. Namely that I have indepent test that test all the CRUD procedures against the biz objects. Now I would like to polish that. How do you setup the testing of child collections? Do you create a test class for each bizobject? Do you also test for children there or do you set up separate testing for the child objest (which first create a parent object)? How do you determine what data to add? Random or what pops into your head?
David D you mentioned that you use an abstract base class and then override for each BizObject. (Or perhaps another one of you)...Would you be willing to post some sample code (pehaps the abstract and one BO class) that I could look at on how to do that. I am still new to OO design (which is why working with CSLA has been so powerfully educational to me) and I have an idea of what it would look like but seeing it would be great and help/confirm I am going in the right direction.
Thanks for all you guys who helps us folks out. You are appreciated.
Seth B Spearman
IMO a child collection is part of the root BO. Therefore any tests for it would be considered part of the "unit tests" for the root BO.
Whether you create the tests in a separate class or not is down to personal choice and preferred style. For example, our current standard is to use the name of the BO as a namespace and have classes for each of the "units" we test. See the ProjectTracker.Tests project on CodePlex for an example of what I mean.
What data you choose to use is again down to personal choice and style.
If the "unit" you are testing is an Add(item) method, then what data you use inside the item is mostly irrelevant. The real tests should be concerned with what happens if you pass a null reference versus what happens if you pass a valid object reference.
However, if the "unit" you are testing is a property setter then the data you choose may be critical to ensure that you get the coverage of all boundary conditions. By that I mean, what happens with null references, empty strings, zero or negative numbers. Usually, this kind of data input should trigger something to happen.
Before you jump into abstract test base classes I would suggest you write a bunch of unit tests first and see what kind of tests you write and how you structure them.
And then when you've got a few of them you might see some patterns emerging. This should then lend itself to a refactoring exercise to create some common reusable code. That might be in the form of helper methods, base classes, code generation templates, snippets, etc.
That way you'll end up with stuff that is right for you work and fits your style.
Thanks David,
That's good advice. I especially like knowing that it is ok to test eht child objects in the tests for the parent.
I have already written some unit tests. On the whole abstraction thing I REALLY want to create as much that is reusable as possible. I just need to figture out how to get the object members into it since they are going to change from object to object. That is what is appealing about the abstraction.
Can you post an URL for the ProjectTracker.Tests...I couldn't find it on codeplex.
Seth
Copyright (c) Marimer LLC