In my investigation of the Neo4j database I will now turn my attention to the Neo4j browser.
Once Neo4j is installed there will be a small executable that can be used to start the Neo4j database server.
In this blog post I am going to return to my investigation of the graph database Neo4j. So far I have done a brief introduction to Neo 4j and I have shown how easy it is to install Neo 4j in an Azure VM.
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.