Tag Archives: c#

Autofixture: Do() not working? You forgot Without()

I use AutoFixture for generating test data in my unit tests. AutoFixture has served me well, but the documentation doesn’t give great examples of how to use it. The “cheat sheet” has links to the authors blogs, and if you’re not careful you won’t find everything you need. It’s sometimes easy to miss those links.

The other day, I was trying to generate a POCO that had a string property, and I wanted that string property to be constrained to a list of valid values. Since I obviously didn’t want to customize the string type across my entire fixture, I instead customized the parent type with the Do method. I wanted to pass in an action that would randomly select from the list pre-defined values and then assign it to the string property in my class instance. The code was straight-forward, but the string was still being populated with the default AutoFixture value.

Read more »

Using delegates for loose coupling and easy unit testing

In a typical ASP.NET MVC or WebApi project, controller actions often do nothing more than make a service call, map the returned domain object to a view model, and either render a view with the model or simply return it for the framework to serialize as JSON. Using AutoMapper, a simplified WebApi controller action may look something like

public EmployeeViewModel GetEmployee(string employeeName)
{
  var employee = _employeeService.GetByName(employeeName);
  var viewModel = Mapper.Map<EmployeeViewModel>(employee);
  return viewModel;
}

This is a pretty common but difficult to test pattern because of the static Mapper dependency. You can’t actually unit test the controller action without having a properly (or at least minimally) configured static Mapper. New versions of AutoMapper provide different ways to solve this problem, like the injectable IMapper interface, but I want to demonstrate another method to reduce coupling and ease unit testing.

In this entry, I’ll demonstrate how to get rid of the static Mapper dependency without using the IMapper interface, which exposes several overloads to map one data type to another, or creating your own interface that serves a similar purpose. Instead, we’ll inject a delegate whose signature is very expressive.

public delegate TDest MapperFunc<in TSrc, out TDest>(TSrc source);

Read more »

If Akka.TestKit.NUnit tests are not running, check your package versions

As of this writing, Akka.TestUnit.NUnit and NUnit 3 are incompatible with one another. Specifically, package version 1.0.5 and NUnit 3.0.1. I’ve opened an issue with the Akka.net team (Issue 1651) so you can watch it for the resolution to this problem.

I was trying to test Akka.net actors in a project that was already using NUnit 3.x. I wrote the tests, but when I ran them with the ReSharper test runner, they would show up for just a split-second and then disappear. I thought that maybe it was the ReSharper test runner since that very day I had to upgrade from R# 9 to R# 10 to get the NUnit 3 support. I tried running the tests from the NUnit 3 console runner and experienced the same thing, though. The tests weren’t failing or marked ignored, or even “not run”, the test runner just didn’t pick them up at all. With a little help from the good folks at the Akka.net Gitter chat, I was able to get my tests running by downgrading to NUnit 2.6. I suppose it is a “known” issue but maybe not that well known since there was no issue logged for it ?

Replace switch statements with dictionaries

I don’t care for switch statements in C#. They’re a poor substitution for pattern matching. They require a compile time constant like a string, an enum, or an integral. Because of that restriction, they are not even a good replacement for giant if-else constructs, which was their intended purpose. On top of all of that, their syntax is ugly and error-prone. Ever left out a break; and saw some unintended consequences due to the fall through?

In general, I regard switch statements a code smell. Usually, some factoring could remove the need for them completely. However, there are times when you just have to make due with switch statements, like you’re on a tight deadline so refactoring is out the question, or maybe there just isn’t a good way to refactor it out of existence. If you’re stuck with a switch statement, there may be a better solution. Let me show you how to turn ugly switch statements into something more manageable.

Read more »

Should, ShouldBe; a silly mistake using FluentAssertions

I use FluentAssertions for all of my asserting needs. I like it’s API better than the assert methods you get with the .Net framework, and the FluentAssertions library provides an overall more fully featured set of assertion options. It’s open-source and continually updated, too, which makes it all right in my book. Sometimes, though, while I’m furiously writing tests, I get this test failure signature and it catches me off guard.

Subject has property Subject that the other object does not have.

Here’s a sample NUnit test case that would cause this particular error.

internal class MistakesTests
{
    [Test]
    public void ThisDumbThingIKeepDoing()
    {
        var thing = new Thing { FirstName = "Nelson" };
        var thing2 = new Thing { FirstName = "Nelson" };
        // This should definitely pass, right?
        thing.Should().ShouldBeEquivalentTo(thing2);
    }
    private class Thing
    {
        public string FirstName { get; set; }
    }
}

As you can see, I’m just doing a very simple object graph comparison, but it isn’t working as I intended. Can you spot the error?

Whereas I should be calling ShouldBeEquivalentTo on my Thing instance, I’m actually calling it on an instance of ObjectAssertions type from the FluentAssertions library. Whoops! ?

Don’t throw exceptions with internal constructors

I ran into an annoying problem the other day when working with a 3rd party library, mail.dll.  You see, mail.dll exposes library methods for sending email messages to an SMTP server, functionality common enough that you should never have to write it yourself.  While I’ve been pleased with its ability to perform SMTP conversations, I have not been impressed with its use of exceptions.

When the mail.dll SMTP library fails to connect or get a response from the SMTP server to which it is connecting, it throws a mail.dll-specific custom exception, SmtpResponseException.  Likewise for the IMAP and POP3 libraries, if a failure happens during client interaction with the server, an ImapResponseException or Pop3ResponseException is thrown, respectively.  Since, in the normal course of a properly configured mail client’s operation, the expectation is that the server will respond appropriately, I don’t have a problem with these libraries throwing exceptions.  They are understood and can be handled by the consuming application.

Here’s the annoying bit. The custom exceptions thrown by mail.dll only have internal constructors and cannot be thrown outside of the mail.dll assembly.  In this article, I’ll talk about why your library should not throw exceptions that the consuming code cannot throw itself and a workaround when someone else’s library does.

Read more »