I've installed nUnit and written a test module successfully. But it doesn't do anything very useful and I'm ready to correct that.
So I'm curious to know what kinds of tests do CSLAers write to test their BOs? Is there a standard suite that you always do for the standard BOs?
And then you only write special test for Command objects' special behaviors and your non-CSLA objects in the application?
How does CodeGeneration affect your use? Do you test less because of it? Do you generate tests?
Sure, these are a lot of questions, but what a great resource this thread will be for so many! And it will be easy to find with this title, too!
Thanks for all your contributions here,
Unit tests will vary depending on the complexity of your objects and will be more complex the deeper your heirarchy becomes.
Typically, you will want to 'actuate' each of your objects properties to make sure that everything is being set and retrieved properly. This may seem like a pain, but a true tester will tell you that snippets like:
myObject.PropertyA = someValue;
Assert.AreEqual(myObject.PropertyA, someValue);
can really uncover some basic errors that could plague you if only testing higher level functionality. So, don't discount this type of testing. Plus, you only have to take the time to write the test once (before coding if you buy into a test-driven approach) and will be able to re-run the test over and over to make sure everything continues to work right as your efforts go on (regression, integration & system testing).
Then, you will want to test that each of your operations do as expected. This will include method calls and evaluating any overloaded operators. Same rule here: may seem basic and like grunt work, but it pays off when the tests find a type-o or logic error.
As you get into higher level objects, such as BO's, you will add tests for things like CRUD operations. A typical test here is to create an object, save it to the DB, retrieve a copy of it and make sure that what you retrieved matches the original. As you can tell, this tests a whole lot of things including not only your data access code, stored procedures and DB schema but your property accessors, Equals implementation, etc. This is why it's good to perform your tests all the way down your heirarchy and to test everything because if the comparison to your retreived object fails, it sure would be nice to have an idea that it was something as simple as a cross-wired property get accessor before you spend hours and handfuls of hair troubleshooting your sprocs and data access code.
Nice thing about NUnit is that it really doesn't care what you are doing within your test methods, so you can use the tool beyond simple unit testing. Once you start dealing with communication and collaboration with other objects, you've actually stepped out of unit testing and into integration testing. But this isn't a problem with NUnit where a test is a test no matter what you are doing within it.
Just remember to keep your testing code organized with your class library so that it is there to re-use quickly and easily later. I know many people like to put there test fixtures (classes) in other assemblies (as Rocky did), but with a simple #if DEBUG compiler switch, you can keep them in the same library and make them disappear for production release. Having it there helps to make sure that you make use of the tests as your work continues. Out of site, out of mind, ya know?
I suggest you take a look at the source code that accompanies the book. Rocky has included his unit tests in the Csla.Test application. That may help give you an idea of the kind of things to do in your own tests.
Hope that helps.
SonOfPirate:
Just remember to keep your testing code organized with your class library so that it is there to re-use quickly and easily later. I know many people like to put there test fixtures (classes) in other assemblies (as Rocky did), but with a simple #if DEBUG compiler switch, you can keep them in the same library and make them disappear for production release. Having it there helps to make sure that you make use of the tests as your work continues. Out of site, out of mind, ya know?
No, unfortunately MS hasn't given us the ability to distinguish references by configuration (yet?). So, if you have the test classes in the same assembly, you'd have to live with it being a part of the build.
Good point. I will reconsider this point-of-view/practice.
Copyright (c) Marimer LLC