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).
I have been working for a while on a library of simple components, which I have called Project “Naif”. Naif is the masculine form of the more common adjective “naïve”. Both words are originally French and while naïve is in fairly common usage in English, naif is much less used. But they mean the same thing – marked by unaffected simplicity - as defined by Merriam Webster
A couple of months ago I blogged about Neo4j, a graph database that I plan to check out. I didn’t get much chance to play with it, and a couple of weeks ago I found myself having to re-install Windows on both my desktop computer and my Surface Pro.
As an ASP.NET MVP I get 160 credits per month of Azure services, enough to run 2-3 small VMs, so I thought it would make sense to install Neo4j on an Azure VM so it would be accessible whichever computer I was working at.
In this series I intend to present Tips and Tricks as well as some good patterns and practices for DNN development. In this first post lets take a look at the so-called “SOLID” Design Principles. These are a series of principles designed to help you build good products.
Its been a while since I posted a blog in my Knockout series. In the last couple of posts in this series we reviewed how Knockout implements the concept of Observable Arrays. Observable Arrays support the idea of detecting when objects are added and removed from the array. For a complete solution though we actually will want the array to contain observable objects so we can also detect when changes are made to each item.
Over the last couple of years I have been trying to get a handle on the “new” database technologies lumped together under the NoSQL banner. In that respect I have posted several articles to this blog.
More recently my focus has shifted from looking at NoSQL databases as a group to diving in deeper to a few select “NoSQL” databases. The one that intrigues me most is Neo4j – a graph database.