In this DNN Development Tips series I have blogged quite a bit about testing. But how can we ensure our classes are testable?
In an earlier blog I described the use of the DnnExceptionFilterAttribute which can be used to simplify the exception handling in Services Framework action methods. In this blog I turn my attention to another, more generic attribute that you can apply to your action methods.
In a previous article in this series of blog posts, I introduced Moq (Mock-you) – the mocking framework we are using in DNN to generate Mock objects for testing.
This DNN Development Tip is a short one – but an important one.
There is a facebook meme that has been doing the rounds recently that amongst other things talks about good versus bad commenting of code.
In a previous article in this series of blog posts, I described the different Test Doubles that can be used when unit testing your application.
One of the tenets of Unit Testing is that in order to test a piece of code we often need to create some alternate implementation of one or more of the Interfaces involved in a test. This concept is generally called a Test Double. However there are many types of Test Double, and there is some degree of confusion about the types of doubles used.
One of the biggest challenges in writing Unit Tests - at least when you write them after you have created the actual code, rather than in a Test Driven Development style, is determining what should be tested.
Often when writing DNN Service Framework methods (based on ASP.NET Web API) you find yourself writing the same boiler plate error-handling code.
Over the last few years at DNN Corp we have placed an increase reliance on automated testing – both Unit Tests and Integration Tests, using NUnit and Moq.
As part of this series on DNN Development Tips, I hope to “uncover” little know classes/methods - in the DNN Framework (and any of the 3rd party libraries that we use, such as Telerik or the .NET framework itself).