Effective Unit Testing for DNN. James McKee Solutions Developer / Enterprise Architect @ punkcoder. THANKS TO ALL OF OUR GENEROUS SPONSORS!. About Me. Almost 10 years working .NET Consultant 7 years 7 Companies in the Fortune 100 10 total in the Fortune 500
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
James McKee Solutions Developer / Enterprise Architect@punkcoder
Almost 10 years working .NET
Consultant 7 years
7 Companies in the Fortune 100
10 total in the Fortune 500
Currently with BlueBolt Solutions
Enterprise Architect for Bravo-Squared Software
New to the DNN Scene
So to gauge the audience:
Know what unit tests are?
Realize that unit tests are something that you write not something you do?
Think that they are a great idea but something that you don’t have time for?
Unit Tests are hard
Unit Tests are for people who don’t know how to program.
My project isn’t big enough to need unit tests.
I’m the only one working on my project.
My client doesn’t pay for unit tests.
We are on a compressed time line, we don’t have time for unit tests.
Unit Test as a function of code
Unit Test vs. Functional Test
Major implementations should interact through the veil of an interface.
Programming to an interface improves modularity.
It encourages looser coupling.
Mocking classes can get complicated.
It’s just good design!
An artificial object that mimics the behavior of a complicated class for the purpose of simplifying testing.
You would mock the following in your tests:
File System Calls
Web Service Calls
Many of the interaction points for modules and scheduled tasks are complicated and do not supply Interfaces.
Functionality such as database access requires instantiation of classes originating from DNN.
Ninject is a lightweight, full featured IoC container for use with dependency injection.
Available at http://www.ninject.org/
To make the application more testable we will create 2 Standard Kernels that will be responsible for filling dependencies:
In production code we will use the real kernel
In testing we will use the testing kernel to return mock objects.
In scheduled tasks this will be inserted at the beginning of custom code.
In views the presenter will be instantiated from Kernel
Because of state some objects don’t work well with direct instantiation.
DataContext is a good example. Reusing a data context for multiple calls can result in a time out, that leads to exception, which leads to GC.
To avoid this create factory classes that produce instance classes.
xUnit, spiritual successor to NUnit
Visual Studio Built-In
Suffers from problems related testing x86/x64 in the same project.
Integrates well with performance testing and can use unit tests for load testing
When it comes to unit testing, there is a very fine line between code reuse and masking issues.
If possible write your code as test driven, this will produce leaner code.
Aim for the 90% mark, but 80% is the accepted boundary.
Use asserts carefully, make sure that what you are asserting is the actual correct behavior.