Today I realised that I’d forgotten how spoilt I am using Resharper and dotCover to run my unit tests. Put another way I’d forgotten how badly Visual Studio plays with any other unit test frameworks other than MS Test! I’m used to and really like the fluent API style of NUnit’s Assert.That(…) syntax so having to fall back to MS Test always feels like a step back. If you ever find yourself in a situation . . .
Leading on from the previous blog post on reducing code noise when checking for null parameters, these help functions can be utilised to further reduce code noise that generally occurs in class constructors. Most constructors are purely made up of the following duplicated checking/assignment code. Again putting together a small helper function, making use of the previous Throw class can remove 90% of the previous argument checking/assignment code resulting in: Get the code from GitHub.
The problem with writing defensive fail early code, it doesn’t take long before methods are 70% argument checking, 30% logic: Code contracts can be a great way to move code out of the method body, but how can you clean up the code just through traditional refactoring? For the last few projects I’ve worked on, I’ve been using a small helper class that abstracts all the conditional code out, leaving just a single line call . . .
When I first started looking into Windows Workflow one of the first things that I liked about it was how it separated responsibilities. The workflow was responsible for handling the procedural logic with all its conditional statements, etc. Whilst individual code activities could be written to handle the business logic processing; created in small easily re-usable components. To try and realise my original perception this series of blog posts will cover the unit testing of . . .
In this post, we will extend the query functionality to handle stored procedures with parameters. To do this we need to create a new query type interface with an example implementation: Now that we have the ability to create stored procedure queries we need something to handle them. To do this we need a concrete implementation of the interface “IHandleAQuery”: Finally, we update our factory to handle the new query interface and return the correct . . .
In part 3 we created a SQL repository object that took a populated instance of IQuery to select/return an enumerable list of objects. A limitation of the repository was that the query had to be text-based, it couldn’t handle stored procedures and/or parameters. By incorporating an abstract factory pattern we can extend the functionality to handle different types of query. The original code inside “SqlRepository.Get(…)” needs to be changed from: To: The static factory class . . .
In Part 1 of this series, we started with a basic Data-Reader / SQL Connection/Command pattern and illustrated how it is possible to abstract the parsing of the Data Reader into a standalone object that can be fully unit tested in isolation of the calling code. In Part 2 of the series we made a very simple optimisation to the “DataReader” convertor and updated the tests to capture/verify the changes. In part 3 of the . . .
When writing or using an implementation of IComparer.Compare(x,y) you encounter the following error message: Unable to sort because the IComparer.Compare() method returns inconsistent results. Either a value does not compare equal to itself, or one value repeatedly compared to another value yields different results It is highly likely that the code within the “Compare” statement is throwing an exception. We encountered this problem when trying to access an array out of bounds in a particular . . .
It seems that a common aim when first starting out in unit testing is to obtain 100% code coverage with our unit tests. This single metric is the defining goal and once obtained a new piece of functionality is targeted. After all, if you have 100% code coverage you can’t get better than that, can you? It’s probably fair to say that it’s taken me several years and a few failed attempts at test-driven development . . .
In Part 1 of this series, we started with a basic Data-Reader / SQL Connection/Command pattern and illustrated how it is possible to abstract the parsing of the Data Reader into a standalone object that can be fully unit tested in isolation of the calling code. In Part two of the series, we will highlight a very simple optimisation that can be made to the “DataReader” convertor and the required update to the tests to . . .