4 common mistakes when writing your first unit tests

Last time, we covered how to write our first unit tests with C# and MSTest. We started from a Console program and converted it into our first unit tests. We wrote those tests for Stringie, a (fictional) library to manipulate strings with more readable methods. This time, we will cover how NOT to write unit tests. These are four common mistakes we should avoid when writing our first unit tests.

1. Do not follow a naming convention

First, keep your tests in the right place. Have one test project per project, one test class per class. Add the suffix “Tests” in the name of your test projects and classes.

Choose a naming convention for your test names and stick to it.

In our previous post, we covered two naming conventions. An “ItShould” sentence and the three-part name separated with underscores. You can choose the one you like the most.

That time, for Stringie Remove() method, we wrote test names like:

  • “Remove_ASubstring_RemovesThatSubstring”
  • “Remove_NoParameters_ReturnsEmpty”

Every test should tell the scenario under test and the expected result. We shouldn’t worry about long test names. But, let’s stop naming our tests: Test1, Test2 and so on.

Don’t prefix our test names with “Test”. If we’re using a testing framework that doesn’t need keywords in our test names, let’s stop doing that. With MSTest, we have attributes like [TestClass] and [TestMethod] to mark our methods as tests.

Also, don’t use filler words like “Success” or “IsCorrect” in our test names. Instead, let’s tell what “success” and “correct” means for that test. Is it a successful test because it doesn’t throw exceptions? Is it successful because it returns a value? Make your test names easy to understand.

2. Do not use the right assertion methods

Follow the Arrange/Act/Assert principle. Separate the body of your tests to differentiate these three parts.

For the Assert part of your tests, make sure to use an assertion library. MSTest, NUnit and XUnit are the three most popular ones for C#.

Use the right assertion methods of your library. For example, MSTest has assertion methods for strings, collections and other objects. For a list of the most common MSTest assertions methods, check the Cheatsheet in Unit Testing 101.

Please, don’t do.

Assert.AreEqual(null, result);
// or
Assert.AreEqual(true, anotherResult);

Prefer.

Assert.IsNull(result);
// or
Assert.IsTrue(anotherResult);
Unit Testing 101
Arrggg! Photo by Steve Johnson on Unsplash

3. Do not have a single assertion per test

Have only one Act and Assert part in your tests. Don’t repeat the same Act part with different test values in a single test.

Please, avoid writing test like this one.

[TestMethod]
public void Remove_SubstringWithDifferentCase_RemovesSubstring()
{
    var str = "Hello, world!";

    var transformed = str.RemoveAll("Hello").IgnoringCase();
    Assert.AreEqual(", world!", transformed);

    transformed = str.RemoveAll("HELLO").IgnoringCase();
    Assert.AreEqual(", world!", transformed);

    transformed = str.RemoveAll("HeLlO").IgnoringCase();
    Assert.AreEqual(", world!", transformed);
}

Or like this one.

[TestMethod]
public void Remove_SubstringWithDifferentCase_RemovesSubstring()
{
    var str = "Hello, world!";

    var testCases = new string[]
    {
        "Hello",
        "HELLO",
        "HeLlO"
    };
    string transformed;
    foreach (var str in testCases)
    {
        transformed = str.RemoveAll("Hello").IgnoringCase();
        Assert.AreEqual(", world!", transformed);
    }
}

If we want to test the same scenario with different test values, let’s use parameterized tests.

Parameterized tests with MSTest

To write a parameterized test with MSTest, we can follow these steps:

  • Replace the [TestMethod] attribute with the [DataTestMethod] attribute in your test.
  • Add [DataRow] attributes for each set of test values.
  • Add parameters for each test value inside the [DataRow] attributes.
  • Use the input parameters in your test to arrange, act or assert.

Let’s convert the previous test with many test values into a parameterized test.

[DataTestMethod]
[DataRow("Hello")]
[DataRow("HELLO")]
[DataRow("HeLlo")]
public void Remove_SubstringWithDifferentCase_RemovesSubstring(string substringToRemove)
{
    var str = "Hello, world!";

    var transformed = str.RemoveAll(substringToRemove).IgnoringCase();

    Assert.AreEqual(", world!", transformed);
}

4. Repeat logic in your assertions

I can’t stress this enough. Don’t repeat the logic under test in your assertions. Use known, hard-coded, pre-calculated values, instead.

We shouldn’t copy the tested logic and paste it in a private method in our tests to use it in our assertions. We will have code, and bugs, in two places.

Please, don’t write assertions like the one in this test.

[TestMethod]
public void Remove_ASubstring_RemovesThatSubstringFromTheEnd()
{
    string str = "Hello, world!";

    string transformed = str.Remove("world!").From(The.End);

    var position = str.IndexOf("world!");
    var expected = str.Substring(0, position);
    Assert.AreEqual(expected, transformed);
}

For this test, instead of using the Substring() method to remove the input string, use a known expected value. Write Assert.AreEqual("Hello,", transformed). For example,

[TestMethod]
public void Remove_ASubstring_RemovesThatSubstringFromTheEnd()
{
    string str = "Hello, world!";

    string transformed = str.Remove("world!").From(The.End);

    // Let's use a known value in our assertions
    Assert.AreEqual("Hello,", transformed)
}

Voilà! These are four common misatkes mistakes when writing our first unit tests. Remember to put your test in the right places following a naming convention. Also, keep one assertion per test and don’t repeat logic in your assertions. You will have better tests avoiding these mistakes.

If you want to practice identifying and fixing these mistakes, check my Unit Testing 101 repository. You will find the tests that Stringie developers wrote and some other misatkes mistakes they made. Your mission, Jim, should you choose to accept it, is to fix them.

canro91/Testing101 - GitHub

If you’re new to unit testing, read my post Unit Testing 101 to write your first unit tests in C#. For more advanced tips on writing unit tests, check my post how to write good unit tests.

Happy testing!

Unit Testing 101: Write your first unit test in C# with MSTest

Do you want to start writing unit tests and you don’t know how to start? Were you asked to write some unit tests on a past interview? Let’s see what is a unit test and how to write your first unit tests in C#.

What is a Unit test?

The book The Art of Unit Testing defines a unit test as “an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.”

From the previous definition, a unit of work is any logic exposed through public methods. Often, a unit of work returns a value, changes the internals of the system, or makes an external invocation.

If that definition answers how to test public methods, we might ask: ‘What about private methods?’ Short answer: we don’t test them. We test private methods when we call our code through its public methods.

In short, a unit test is code that invokes some code under test and verifies a given behavior of that code.

Why should we write unit tests?

Have you ever needed to change your code, but you were concerned about breaking something? I’ve been there too.

The main reason to write unit tests is to gain confidence. Unit tests allow us to make changes, with confidence that they will work. Unit tests allow change.

Unit tests work like a “safety net” to prevent us from breaking things when we add features or change our codebase.

In addition, unit tests work like a living documentation. The first end-user of our code is our unit tests. If we want to know what a library does, we should check its unit tests. Often, we will find not-documented features in the tests.

Someone driving a car with his seat-belt on
Your unit tests work like a safety net. Photo by Farzanah Rosli on Unsplash

What makes a good unit test?

Now, we know what is a unit test and why we should write them. The next question we need to answer is: ‘What makes a test a good unit test?’ Let’s see what all good unit tests have in common.

Our tests should run quickly. The longer our tests take to run, the less frequent we run them. And, if we don’t run our tests often, we have doors opened to bugs.

Our tests should run in any order. Tests shouldn’t depend on the output of previous tests to run. A test should create its own state and not rely upon the state of other tests.

Our tests should be deterministic. No matter how many times we run our tests, they should either fail or pass every time. We don’t want our test to use random input, for example.

Our tests should validate themselves. We shouldn’t debug our tests to make sure they passed or failed. Each test should determine the success or failure of the tested behavior. Imagine we have hundreds of tests and to make sure they pass, we have to debug every one of them. What’s the point, then?

“It could be consider unprofessional to write code without tests” - Robert Martin, The Clean Coder

Let’s write our first unit test

Let’s write some unit tests for Stringie, a (fictional) library to manipulate strings with more readable methods.

One of Stringie methods is Remove(). It removes chunks of text from an string. For example, Remove() receives a substring to remove. Otherwise it returns an empty string if we don’t pass any parameters.

"Hello, world!".Remove("Hello");
// ", world!"

"Hello, world!".Remove();
// ""

Here’s the implementation of the Remove() method for the scenario without parameters.

namespace Stringie
{
    public static class RemoveExtensions
    {
        public static RemoveString Remove(this string source)
        {
            return new RemoveString(source);
        }
    }

    public class RemoveString
    {
        private readonly string _source;

        internal RemoveString(string source)
        {
            _source = source;
        }

        public static implicit operator string(RemoveString removeString)
        {
            return removeString.ToString();
        }

        public override string ToString()
        {
            return _source != null ? string.Empty : null;
        }
    }
}

Let’s write some tests for the Remove() method. We can write a Console program to test these two scenarios.

using Stringie;
using System;

namespace TestProject
{
    class Program
    {
        static void Main(string[] args)
        {
            var helloRemoved = "Hello, world!".Remove("Hello");
            if (helloRemoved == ", world!")
            {
                Console.WriteLine("Remove Hello OK");
            }
            else
            {
                Console.WriteLine($"Remove Hello failed. Expected: ', world!'. But it was: '{helloRemoved}'");
            }

            var empty = "Hello, world!".Remove();
            if (string.IsNullOrEmpty(empty))
            {
                Console.WriteLine("Remove: OK");
            }
            else
            {
                Console.WriteLine($"Remove failed. Expected: ''. But it was: {empty}");
            }

            Console.ReadKey();
        }
    }
}

However, these aren’t real unit tests. They run quickly, but they don’t run in any order and they don’t validate themselves.

If you want to follow along, check the repository Testing101 on GitHub

Where should we put our tests?

Let’s create a new project. Let’s add to the solution containing Stringie a new project of type “MSTest Test Project (.NET Core)”. Since we’re adding tests for the Stringie project, let’s name our new test project Stringie.UnitTests.

It’s my recommendation to put our unit tests in a test project named after the project they test. We can add the suffix “Tests” or “UnitTests”. For example, if we have a library called MyLibrary, we should name our test project: MyLibrary.UnitTests.

In our new test project, let’s add a reference to the Stringie project.

Visual Studio 'Solution Explorer' showing a new file 'UnitTest1.cs'
Visual Studio Solution Explorer with our new test project

After adding the new test project, Visual Studio created a file UnitTest1.cs. Let’s rename it! We are adding tests for the Remove() method, let’s name this file: RemoveTests.cs.

One way of making our tests easy to find and group is to put our unit tests separated in files named after the unit of work or entry point of the code we’re testing. Let’s add the suffix “Tests”. For a class MyClass, let’s name our file: MyClassTests.

MSTest

Now, let’s see what’s inside our RemoveTests.cs file.

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Stringie.UnitTests
{
    [TestClass]
    public class RemoveTests
    {
        [TestMethod]
        public void TestMethod1()
        {
        }
    }
}

It contains one normal class and method. However, they’re annotated with two unusual attributes: [TestClass] and [TestMethod]. These attributes tell Visual Studio that our file contains unit tests to run.

The TestClass and TestMethod attributes belong to a project called MSTest. Microsoft Test Framework (MSTest) is an open source unit testing framework. MSTest comes installed with Visual Studio.

Unit testing frameworks help us to write and run unit tests. Also, they create reports with the results of our tests. Other common unit testing frameworks include NUnit and XUnit.

How should we name our tests?

Let’s replace the name TestMethod1 with a name that follows a naming convention.

We should use naming conventions to show the feature tested and the purpose behind of our tests. Tests names should tell what they’re testing. A name like TestMethod1 doesn’t say anything about the code under test and the expected result.

One naming convention for our test names uses a sentence to tell what they’re testing. Often these names start with the prefix “ItShould” follow by an action. For our Remove() method, it could be: “ItShouldRemoveASubstring” and “ItShouldReturnEmpty”.

Markers and labels
Tests names should tell what they're testing. Photo by Jon Tyson on Unsplash

Another convention uses underscores to separate the unit of work, the test scenario and the expected behavior in our test names. If we follow this convention for our example tests, we name our tests: Remove_ASubstring_RemovesThatSubstring() and Remove_NoParameters_ReturnsEmpty().

With this convention, we can read our test names out loud like this: “When calling Remove with a substring, then it removes that substring”.

These names could look funny at first glance. We should use compact names in our code. However, when writing unit tests, readability is important. Every test should state the scenario under test and the expected result. We shouldn’t worry about long test names.

Following the second naming convention, our tests look like this:

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Stringie.UnitTests
{
    [TestClass]
    public class RemoveTests
    {
        [TestMethod]
        public void Remove_ASubstring_RemovesThatSubstring()
        {
        }

        [TestMethod]
        public void Remove_NoParameters_ReturnsEmpty()
        {
        }
    }
}

How should we write our tests?

Now, let’s write the body of our tests.

To write our tests, let’s follow the Arrange/Act/Assert (AAA) principle. Each test should contain these three parts.

In the Arrange part, we create input values to call the entry point of the code under test.

In the Act part, we call the entry point to trigger the logic being tested.

In the Assert part, we verify the expected behavior of the code under test.

Let’s use the AAA principle to replace one of our examples with a real test. Also, let’s use line breaks to visually separate the AAA parts.

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Stringie.UnitTests
{
    [TestClass]
    public class RemoveTests
    {
        [TestMethod]
        public void Remove_NoParameters_ReturnsEmpty()
        {
            string str = "Hello, world!";

            string transformed = str.Remove();

            Assert.AreEqual(0, transformed.Length);
        }
    }
}

We used the Assert class from MSTest to write the Assert part of our test. This class contains methods like AreEqual(), IsTrue() and IsNull().

The AreEqual() method checks if the result from a test is equal to an expected value. In our test, we used it to verified the length of the transformed string. We expect it to be zero.

Let’s use a known value in the Assert part instead of repeating the logic under test in the assertions. It’s OK to hardcode some expected values in our tests. We shouldn’t repeat the logic under test in our assertions. For example, we can use well-named constants for our expected values.

Here’s an example of how not to write the Assertion part of our second test.

[TestMethod]
public void Remove_ASubstring_RemovesThatSubstring()
{
    string str = "Hello, world!";

    string transformed = str.Remove("Hello");

    var position = str.IndexOf("Hello");
    var expected = str.Substring(position + 5);
    Assert.AreEqual(expected, transformed);
}

Notice how it uses the Substring() method in the Assert part to find the string without the Hello substring. A better alternative is to use the expected result in the AreEqual() method.

Let’s rewrite our last test to use an expected value instead of repeating the logic being tested.

[TestMethod]
public void Remove_ASubstring_RemovesThatSubstring()
{
    string str = "Hello, world!";

    string transformed = str.Remove("Hello");

    // Here we use the expected result ", world!"
    Assert.AreEqual(", world!", transformed)
}

How can we run a test inside Visual Studio?

To run a test, let’s right click on the [TestMethod] attribute of the test and use “Run Test(s)”. Visual Studio will compile your solution and run the test you clicked on.

After the test runs, let’s go to the “Test Explorer” menu. There we will find the list of tests. A passed test has a green icon. If we don’t have the “Test Explorer”, we can use the “View” menu in Visual Studio and click “Test Explorer” to display it.

Visual Studio 'Test Explorer' showing a passing test
Test Explorer with our first passing test

That’s a passing test! Hurray!

If the result of a test isn’t what was expected, the Assertion methods will throw an AssertFailedException. This exception or any other unexpected exception flags a test as failed.

Cheatsheet

These are some of the most common Assertion methods in MSTest.

Method Function
Assert.AreEqual Check if the expected value is equal to the found value
Assert.AreNotEqual Check if the expected value isn’t equal to the found value
Assert.IsTrue Check if the found value is true
Assert.IsFalse Check if the found value is false
Assert.IsNull Check if the found value is null
Assert.IsNotNull Check if the found value isn’t null
Assert.ThrowsException Check if a method throws an exception
Assert.ThrowsExceptionAsync Check if an async method throws an exception
StringAssert.Contains Check if a found string contains a substring
StringAssert.Matches Check if a found string matches a regular expression
StringAssert.DoesNotMatch Check if a found string doesn’t matches a regular expression
CollectionAssert.AreEquivalent Check if two collections contain the same elements
CollectionAssert.AreNotEquivalent Check if two collections don’t contain the same elements
CollectionAssert.Contains Check if a collection contains an element
CollectionAssert.DoesNotContain Check if a collection doesn’t contain an element

Conclusion

Voilà! That’s how you write your first unit tests in C# with MSTest. Don’t forget to follow naming conventions and use the Assert class when writing unit tests.

If you want to practice writing more test for Stringie, check my Unit Testing 101 repository over on GitHub.

canro91/Testing101 - GitHub

In this repo, you will find two lessons. One lesson to write some unit tests and another lesson to fix some unit tests.

This post was originally published on exceptionnotfound.net as part of the Guest Writer Program. I’d like to thank Matthew for helping me to edit this post.

Happy testing!

How not to write Dynamic SQL

Last time, I showed you three tips to debug your Dynamic SQL. The next time you find a query in the plan cache, you can trace down the store procedure that generated it. This time, I will show you how not to write Dynamic SQL.

Dynamic SQL is a string with a query to execute. In a store procedure with optional parameters, Dynamic SQL is used to build a string with only the comparisons for the parameters passed with a non-default value.

Without Dynamic SQL

Let’s go back to the store procedure dbo.usp_SearchUsers from our previous post on Dynamic SQL. This store procedure finds users by display name or location.

Without Dynamic SQL, we end up with funny comparisons in the WHERE clause. First, we check if the optional parameters have value. To then, with an OR, add the right comparisons.

CREATE OR ALTER PROC dbo.usp_SearchUsers
  @SearchDisplayName NVARCHAR(100) = NULL,
  @SearchLocation NVARCHAR(100) = NULL
BEGIN
    
  SELECT TOP 100 *
  FROM dbo.Users u
  WHERE (@SearchDisplayName IS NULL OR DisplayName LIKE @SearchDisplayName)
    AND (@SearchLocation IS NULL OR Location LIKE @SearchLocation);
END
GO

Sometimes, we use the ISNULL or COALESCE functions instead of IS NULL. But, those are variations on the same theme.

The more optional parameters our store procedure has, the worse our query gets. SQL Server will scan more rows than what it needs.

How not to write Dynamic SQL
Photo by Nadine Shaabana on Unsplash

With Dynamic SQL, the wrong way

Probably, we hear about Dynamic SQL somewhere on the Internet and we decide to use it.

Then, we write the next version of our store procedure.

CREATE OR ALTER PROC dbo.usp_SearchUsersWithWrongDynamicSQL
  @SearchDisplayName NVARCHAR(100) = NULL,
  @SearchLocation NVARCHAR(100) = NULL
AS
BEGIN
 
  DECLARE @StringToExecute NVARCHAR(4000);
    
  SET @StringToExecute = N'SELECT TOP 100 *
  FROM dbo.Users u
  WHERE (@SearchDisplayName IS NULL OR DisplayName LIKE @SearchDisplayName)
    AND (@SearchLocation IS NULL OR Location LIKE @SearchLocation);';

  EXEC sp_executesql @StringToExecute, 
    N'@SearchDisplayName nvarchar(100), @SearchLocation nvarchar(100)', 
    @SearchDisplayName, @SearchLocation;
END
GO

We moved the same query to a string in a Dynamic SQL. That won’t make any difference between the execution plans of both versions. We only put makeup to the same problem. Arggg!

With Dynamic SQL, the right way

With Dynamic SQL, we want to create smaller queries for the different set of parameters passed to our store procedure. We need to add only the conditions for the parameter passed with value.

CREATE OR ALTER PROC dbo.usp_SearchUsersWithDynamicSQL
  @SearchDisplayName NVARCHAR(100) = NULL,
  @SearchLocation NVARCHAR(100) = NULL
AS
BEGIN
 
  DECLARE @StringToExecute NVARCHAR(4000);
    
  SET @StringToExecute = N'SELECT TOP 100 *
  FROM dbo.Users u
  WHERE 1 = 1';

  IF @SearchDisplayName IS NOT NULL
    SET @StringToExecute = @StringToExecute + N' AND DisplayName LIKE @SearchDisplayName ';

  IF @SearchLocation IS NOT NULL
    SET @StringToExecute = @StringToExecute + N' AND Location LIKE @SearchLocation ';

  EXEC sp_executesql @StringToExecute, 
    N'@SearchDisplayName NVARCHAR(100), @SearchLocation NVARCHAR(100)', 
    @SearchDisplayName, @SearchLocation;
END
GO

Notice the two IF statements. Our store procedure will generate one plan for each set of parameters. This time, SQL Server chooses the right indexes to run the query. That’s the point of using Dynamic SQL.

Voilà! That’s how NOT to write a store procedure with optional parameters with Dynamic SQL. Notice that to make things simple, we didn’t follow all the tips from the previous post to make our Dynamic SQL easier to debug.

If you’re interested in more content about SQL and SQL Server, check my posts on Six SQL Server performance tuning tips and How to format your SQL queries.

Happy coding!

TIL: How to convert 2-digit year to 4-digit year in C#

Today I was working with credit cards and I needed to convert a 2-digit year to a 4-digit one in C#. The first thing that came to my mind was adding 2000 to it. But it didn’t feel right. It wouldn’t be a problem in hundreds of years.

To convert 2-digit year into a 4-digit year, you can use the ToFourDigitYear method inside the Calendar class of your current culture.

CultureInfo.CurrentCulture.Calendar.ToFourDigitYear(21)
// 2021

But, if you’re working with a string containing a date, you can create a custom CultureInfo instance and set the maximum year to 2099. After that, you can parse the string holding the date with the custom culture. Et voilà!

CultureInfo culture = new CultureInfo("en-US");
culture.Calendar.TwoDigitYearMax = 2099;

string dateString = "1 Jan 21";
DateTime.TryParse(dateString, culture, DateTimeStyles.None, out var result);
// true, 1/1/2021 12:00:00 AM

Sources: Convert a two digit year, Parse string dates with two digit year

Visual Studio snippets for Moq

These days, I use Moq a lot. There are things I like and I don’t like about Moq. But it’s simple and easy to use.

I use the same three or four Moq methods all the time. I decided to create snippets inside Visual Studio to avoid typing the same method names every time. These are the snippets I use.

Create a Mock

mn to create a Mock
Use mn to create a Mock

Setup and Return

mr to Setup/Return
Use mr to Setup/Return

Setup and ThrowsException

mt to Setup/ThrowsException
Use mt to Setup/ThrowsException

Also, you can use mra and mta for the asynchronous version of Return and ThrowsException respectively.

If you want to use the same snippets I use, donwload the snippets file from VSMoqSnippets repository. Head to Visual Studio. From the “Tools” menu, choose “Code Snippets Manager” and import the snippets file.

canro91/VSMoqSnippets - GitHub

Voilà! Those are the snippets I use for Moq. For tips on writing unit tests, check my post on how to write good unit tests. Also, check my Visual Studio setup for more settings and extensions inside Visual Studio.

Happy coding!