Unit testing best practices (edit)
- SOLID Principles
- Code Coverage
- Unit Testing
- ASP.NET MVC Controller
- Asynchronous Code
- Multi-Threaded code
- Loose Coupling
- Tight Coupling
How should I unit test threaded code?
How should I unit test threaded code?
Unified Concurrency I - Introduction - CodeProject (HAY HAY HAY)
Request, Response, Cookies, Session
NET Core 2: Why xUnit and not NUnit or MSTest - DEV (HAY HAY HAY)
What is object oriented design? What is it all about? What are it's benefits? What are it's costs? It may seem silly to ask these questions in a day and age when virtually every software developer is using an object oriented language of some kind. Yet the question is important because, it seems to me, that most of us use those languages without knowing why, and without knowing how to get the the most benefit out of them.
Of all the revolutions that have occurred in our industry, two have been so successful that they have permeated our mentality to the extent that we take them for granted. Structured Programming and Object Oriented Programming. All of our mainstream modern languages are strongly influenced by these two disciplines. Indeed, it has become difficult to write a program that does not have the external appearance of both structured programming and object oriented programming. Our mainstream languages do not have goto, and therefore appear to obey the most famous proscription of structured programming. Most of our mainstream languages are class based and do not support functions or variables that are not within a class, therefore they appear to obey the most obvious trappings of object oriented programming.
Programs written in these languages may look structured and object oriented, but looks can be deceiving. All too often today's programmers are unaware of the principles that are the foundation of the disciplines that their languages were derived around. In another blog I'll discuss the principles of structured programming. In this blog I want to talk about the principles of object oriented programming.
In March of 1995, in comp. object, I wrote an article that was the first glimmer of a set of principles for OOD that I have written about many times since. You'll see them documented in my PPP book, and in many articles on the object mentor website, including a well known summary.
These principles expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects. This is not to say that OO is a poor tool for conceptualization of the problem space, or that it is not a good venue for creating models. Certainly many people get value out of these aspects of OO. The principles, however, focus very tightly on dependency management.
Dependency Management is an issue that most of us have faced. Whenever we bring up on our screens a nasty batch of tangled legacy code, we are experiencing the results of poor dependency management. Poor dependency management leads to code that is hard to change, fragile, and non-reusable. Indeed, I talk about several different design smells in the PPP book, all relating to dependency management. On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable. So dependency management, and therefore these principles, are at the foundation of the -ilities that software developers desire.
The first five principles are principles of class design. They are:
|SRP||The Single Responsibility Principle||A class should have one, and only one, reason to change.|
|OCP||The Open Closed Principle||You should be able to extend a classes behavior, without modifying it.|
|LSP||The Liskov Substitution Principle||Derived classes must be substitutable for their base classes.|
|ISP||The Interface Segregation Principle||Make fine grained interfaces that are client specific.|
|DIP||The Dependency Inversion Principle||Depend on abstractions, not on concretions.|
The next six principles are about packages. In this context a package is a binary deliverable like a .jar file, or a dll as opposed to a namespace like a java package or a C++ namespace.
The first three package principles are about package cohesion, they tell us what to put inside packages:
|REP||The Release Reuse Equivalency Principle||The granule of reuse is the granule of release.|
|CCP||The Common Closure Principle||Classes that change together are packaged together.|
|CRP||The Common Reuse Principle||Classes that are used together are packaged together.|
The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.
|ADP||The Acyclic Dependencies Principle||The dependency graph of packages must have no cycles.|
|SDP||The Stable Dependencies Principle||Depend in the direction of stability.|
|SAP||The Stable Abstractions Principle||Abstractness increases with stability.|
With a recent new project using NET Core 2, my team and I looked at whether we should move to MS Test(Didn't consider MS Test 2 at that time), stick with NUnit or try xUnit. We had a spike, where I looked into whether we could still use NUnit in case we were not able to use xUnit, as we were not keen on MSTest as an alternative framework. In the end, we decided to give xUnit a go!
xUnit is pretty lean compared to NUnit and MsTest and has been written more recently. The .NET framework has evolved since NUnit was first created. XUnit leverage some of the new features to help developers write cleaner test, as tests should be kept clean and treated as first-class citizens. The authors wanted to codify some rules rather than repeating guidance about “do X” or “don’t do Y". You can read more about why xUnit was created here: https://xunit.github.io/docs/why-did-we-build-xunit-1.0.html.
Some of the reasons why we went with xUnit:
- NUnit was not fully compatible with .NET Core 2 at the time
- We wanted to move away from MS Test, as the team preferred the xUnit and NUnit way of writing tests
- xUnit is aimed at improving test isolation and trying to codify a set of rules to establish a testing standard.
- xUnit [Fact] and [Theory] attributes are extensible, so you can implement your own testing functionality.xUnit doesn’t use Test Lists and .vsmdi files to keep track of your tests.
- Microsoft is using xUnit internally, one of its creators is from Microsoft. xUnit was also created by one of the original authors of NUnit.
- There are no [Setup] and [Teardown] attributes, this is done using the test class’ constructor and an IDisposable. This encourages developers to write cleaner tests.
- xUnit allows us to write less code since its flexibility allows things like subspec which allow you to write only what you need to do. Using tools such as xBehave: http://xbehave.github.io/ and Xunit.Gherkin.Quick.
- xUnit is easier to read and uses intuitive terminology.
An interesting recent article from Uncle Bob on (unit) testing:
A performance (with a new update to Visual Studio 2017) comparison was released a few months after picking our testing framework, comparing NUnit, xUnit and MS Test 2. You can find the blog post from Microsoft here.
Design a Singleton pattern
public class RealSingletonLogic
public void Foo()
//lots of logic here
public class MySingletonHolder
private static RealSingletonLogic _instance;
public static RealSingletonLogic Instance
if (_instance == null)
_instance = new RealSingletonLogic();