Bruno Peeters Technical Blog

Besides writing unit tests, it is also important to be able to maintain them. To improve the maintainability of a unit test, it is important that you can easily see what it is trying to test and how it does this to accomplish this task. To improve the readibility of your unit test, you can use the most widely accepted pattern within unit testing: Arrange, Act and Assert (AAA) pattern.

RhinoMocks is a framework for creating mocked instances, that can be used within unit tests. Since the framework is not to be maintained anymore (last version was in 2010), you can’t use RhinoMocks for example within .Net Standard or .Net Core projects.

A project I was working on was having the same struggle; we had quite a large set of unit tests that where using RhinoMocks. For several reasons, we decided to migrate our projects to .Net Core, which made it impossible to use RhinoMocks anymore. We decided to switch to the Moq framework. In this blog I summed up the most used RhinoMocks constructions and how to port them to Moq.

The software we write, most of the times depend on third-party libraries. Take for example Log4Net or a device driver. The problem in many projects is that the third-library libraries are much interwoven with the production code.

Herein lies a number of problems:

• What if you want to change the library you are using?
• What if the structure the library uses does not meet your design?
• How about unit-testing (think of the fact the library might use local resources like physical devices)?

Uncle Bob states in his clean architecture that within a good design, the whole application isn’t aware of these third-party libraries. Think of a plug-in like ReSharper. At Visual Studio they didn’t have to change anything in their code to support the ReSharper plugin. Only the plugin knows about the existent of the other part of the software.

How can we create such an isolation and separate our libraries from our main architecture?

Read More…

If you want to test your code indeed throws an exception within a certain position, NUnit provides possibilities to test if indeed an exception is thrown. Before NUnit 3 you simply added the attribute ExpectedException(typeof()) as the following example shows:
Read More…

For my employer I’m currently writing a course of design patterns, which I will give this year to a group of my colleagues. Therefore I was looking at the various design patterns that could be interesting for the people to learn. When I prepare such a course, I try to think what kind of thinking errors the students could make. When you do this, you can deep out your story much more and anticipate on questions that can arise.

Read More…