Unit testing best practices

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.

xUnit

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:
http://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html

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.

References:

http://georgemauer.net/2015/05/01/why-not-mstest
https://seankilleen.com/2015/06/xUnit-vs-MSTest/
https://stackify.com/unit-test-frameworks-csharp/
https://xunit.github.io/docs/why-did-we-build-xunit-1.0.html http://blog.cleancoder.com/uncle-bob/2017/05/05/TestDefinitions.html

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
  {
   get
   {
    if (_instance == null)
    {
     _instance = new RealSingletonLogic();
    }
    return _instance;
   }
  }
 }

Tags: Unit testing best practices
Categories: Unit testing best practices
comment

@manhng

Unit testing best practices

Unit testing best practices (edit)

OOP principles

xUnit

Design a Singleton pattern

Recent posts

@manhng

Unit testing best practices

Unit testing best practices (edit)

OOP principles

xUnit

Design a Singleton pattern

Categories

Recent posts

Popular tags