C# – Assert equality in mstest when types may differ

cdata typestesting

I've been working on some MSTest automated test infrastructure, that is testing a tool that merges data sets into SQL Server database tables. The basic structure of the test is to:

Define the incoming dataset using anonymous types
Apply the data using the reconcile tool
Read records from the output tables
Compare result rows to input data, column by column

Example input data:

public class InputData : List<dynamic> {} // Inspired by Massive etc

InputData input = new InputData()
{
    new { ExternalID = 1, PropertyName = "hello", Agent = "test" },
    new { ExternalID = (Int64)2, PropertyName = "fred", Agent = "test" } // Fixes the problem with a cast
};

The issue I'm dealing with, is that the type inferred on my anonymous objects will be an Int32, but the corresponding column in my target table is a bigint, and hence the record will have an Int64 value. As a result, when I use Assert.AreEqual across each column, it fails on any int fields:

Assert.AreEqual failed. Expected:<1 (System.Int32)>. Actual:<1 (System.Int64)>

You can see I have cast the int on my second anonymous object, this can be used to fix the issue. The primary aim of these tests is to make the sample data as slim and easy to read/write as possible, and I'd prefer to avoid the visual noise of all those casts.

I'm thinking about the best way to deal with the assertions. It seems like I should use dedicated assertions based on type. I guess the real question is, how aggressive should I be in converting between types automatically?

Best Answer

Assert.AreEqual is basically just sugar for Assert.IsTrue(object.Equals(...)). If there isn't a known comparison operator for the two argument types, they'll compare false.

dynamic is pretty smart about this, so, for example, (dynamic)(int)1 == (decimal)1.0 evaluates to true. That only works if you use the == operator, though; it won't work if you try to use object.Equals, Assert.AreEqual, ((dynamic)x).Equals(...) or anything similar. Simply casting to dynamic won't work, you need to actually use its == operator. The good news is, the dynamic == allows any operand, which means you can get this to compile in a general-purpose assertion; if the comparison is invalid (e.g. comparing int to string, then it will fail at runtime with a RuntimeBinderException.

The next best thing, if you know they're going to be numeric types, would be to cast them all to Decimal or Double, although note that if you use Double you'll have to take into account the possibility of floating-point rounding error, and you should define equality based on some threshold, typically a multiple of Double.Epsilon. Decimal is a lot simpler unless you know for certain that you'll be dealing with floating point.

I don't think that you really have a lot of other choices. I personally would not recommend string conversion because lots of classes don't override ToString, so you end up comparing two instances of something like System.Collections.Generic.List``1[System.Int32], and your assertion declares that these are equal because they have the same string representation when in fact they are not only different instances but contain completely different elements. So don't do that. String coercion can easily mask serious errors in your tests. Stick to non-lossy, all-or-nothing conversions as above.

Related Solutions

C# Unit Testing – Differences Between Given When Then (GWT) and Arrange Act Assert (AAA)

I think you listed the differences very well in your question, however I'll add my some of my opinions on how I view the two approaches.

AAA is very useful for me when I'm testing my own code. If I'm working on a project or a library for myself, AAA is the way that I go. It lets me set up whatever I need to execute my test and then just test it. It's quick to setup, and quick to verify that my code is working as I expect.

GWT is useful in business environments, where work that is done by programmers needs to be mapped to business value. Business value is mapped by features, and hopefully features that don't introduce bugs. There are many strategies for mapping features to programming tasks, but one of them is through requirements. In my experience, requirements range from user-level requirements all the way down to small tasks for the user to execute. This is useful because it's easy for the managers to understand how the work the programmer is doing is impacting their customers/users, and therefore why the programmers are adding value to their business

User-Level Requirement: Given the warehouse has at least N item(s) in inventory, when a user purchases N item(s), then the warehouse ships N item(s) to the user
System-Level Requirement 1: Given the inventory system has N item(s) in inventory, when a request for N item(s) is input into the inventory system then the inventory system decreases the inventory count for that type of item
System-Level Requirement 2: Given the payment system has N item(s) in inventory, when a request for N item(s) is input into the payment system then the payment system charges the user for N item(s)
...
Programmer-Level Requirement 1: Given 5 sweaters are in inventory, when 3 sweaters are removed from inventory then 2 seaters are left in the inventory
...

This sort of requirement structure allows for a tree-like design where all of the Programmer-Level Requirements map up the tree to the User-Level Requirements. In this way, when a Programmer-Level Requirement fails then you know which User-Level Requirement is affected.

In contrast, an AAA test might look like this. This to me is very programmer-facing and not useful to the business. That's not to say a similar tree structure of requirements couldn't be made from an AAA testing strategy, but nothing in the language of AAA makes it easier to do so.

public void Test_CaseWhereThereAreEnoughSweatersLeft() {
    // Arrange
    // setup Sweater Inventory mock (DB mocks, etc)
    // count = 5
    // when The number of sweaters remaining is request, return count
    // when Inventory is requested to remove N items, then count = count - N

    // Act
    // call the Unit Under Test to remove 3 items from inventory

    // Assert
    // the number of sweaters in the inventory is 2
    // the removal should return indicating a successful removal of items from the inventory
}

public void Test_CaseWhereThereAreNotEnoughSweatersLeft() {
    // Arrange
    // setup Sweater Inventory mock (DB mocks, etc)
    // count = 2
    // when The number of sweaters remaining is request, return count
    // when Inventory is requested to remove N items, then count = count - N

    // Act
    // call the Unit Under Test to remove 3 items from inventory

    // Assert
    // the number of sweaters remaining is still 2
    // the removal should return an error indicating not enough items in the inventory
}

C# Generics – Why Out Type is Generally Last

That's the way function types are normally written:

a → b

is a function that takes an a and returns a b.

(a, b) → c

is a function that takes a tuple of (a, b) and returns a c.

a → b → c

is a function that takes an a and returns a function that takes a b and returns a c (which is the curried version of the second function above).

In all these cases, the inputs come first, then the output. And it makes sense: data flows from input to output, types flow from input to input to output, and we read from left to right.

It also matches with declarations for subroutine prototypes in many languages. E.g. Scala:

// method:
def add(a: Int, b: Int): Int

// function:
(a: Int, b: Int) ⇒ { //body of the function, return type is inferred }

Go:

func add(a int, b int) int

Haskell:

add :: (Int, Int) → Int
-- or more idiomatically:
add :: Int → Int → Int

And so on.

Best Answer

Related Solutions

C# Unit Testing – Differences Between Given When Then (GWT) and Arrange Act Assert (AAA)

C# Generics – Why Out Type is Generally Last

Related Topic