Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Easy Simple <strike>Unit</strike> umm Business Rule Testing (for DotNetNuke and Linq to SQL)

At my day job we have an advanced developer who was given a difficult project where he has to implement a dozen business rules. I’m talking “ask for a blessing before you go in” and “ask for forgiveness when you come out” complicated code.

I watched him work on the code, and he is methodical at writing down the rules and writing a test case to make sure he properly implemented it.  This usually involves creating a “test case” by setting up data in the database just right and then clicking buttons and links and checking the expected output. I have worked with him over a year, and I can assure you he has probably deleted more good code than I have ever written. Everything is properly structured and segmented and the overall design will bring tears to you eyes with the beauty of it’s implementation.

But management keeps asking for major changes.

So I see this developer re-think his design and carefully re-factor his code to accommodate huge changes in requirements. He carefully retests all the existing business rules as he implements the new ones. Sometimes it takes hours for him to properly test everything. The guy is a total pro and he gets the job done.

But, here is the problem. He is a contract programmer, and when he moves on to his next job guess who has to maintain the code… me! 

I had a nightmare where management came up to me and they wanted to “enhance” that code “one more time”. How can I make management understand that it could take me 6 hours to make just one small change to the code? Yes the code is well designed but it simply cannot anticipate all the requirements that are being demanded of it. It constantly has to be re-factored and each re-factoring brings a very real risk of breaking existing code.

Unit Testing

I am sure we have all read blogs on “getting started with unit testing”. They show a simple test that calls a method that returns some prime number. First the test fails because the code has not been written, next, they write the code and the test passes. “Wow this is great” you say, and then look for some examples where they connect to the database.

Now you are wading through a lot of complicated examples to Initialize() and Cleanup() to get the data just right. You are actually spending considerable time to “set-up a valid test” and then return the data to the previous state so the test is repeatable.  When you realize that there is more code to “properly Unit Test” than there is in the project it’s self you come to the conclusion that  it is not worth it. Just fix the bugs as they come, it will take less time.

However, in this case I needed Unit Tests to manage the complexity of the business rules. I really don’t care about “proper code coverage” and “proper isolation”, I just want something to help me so I don’t lie awake at 2:00 am thinking about accidently breaking some very important code.

Easy Unit Business Rule Testing

There is wonderful stuff out there on Unit Testing but I needed something simple and easy. A Unit Test purist would pass out from shock at the manner I butcher the normal Unit Testing paradigm.

The main thing I did was only test the specific methods I cared about, and only for business rule adherence. I load up a bunch of sample data and then toss it into a business object and check the expected result. Since I am using Linq to SQL, it is easy to implement the ‘Repository Pattern” and substitute my sample tables for real ones. The code doesn’t realize that it is not connecting to a real database and produces the same output for the same input every time.

But understand, when others talk about Unit testing, this is not what they mean. You should be testing each method inside the business object. If all tests pass you then know that the any re-factoring “should” not have broken anything.

This is Unit Testing for the guy who buys Life Insurance only if he plans to travel. I just call the methods on the “outside” of the business object and ask for an expected result. If I need to, I can test specific methods “on the inside” (methods that are called by the primary methods).

So it isn’t really Unit Testing, I guess it’s “Business Rule Testing”.

You can read the article here:


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?