Archive for the ‘.Net’ Category

As a continuation to my recent rant about the differences between programmers and developers and how programmers love to code and … well, everything it is mentioned in that post, I felt like sharing a little bit of fun I had with this stackoverflow question.

Since it had already been answered and actually there was a little debate going on about the pros and cons of the accepted answer I was about to close it and look for something else when I decided to have a little bit of fun and make the solution generic.

Not like it was difficult, after a couple of minutes I had this:

    public class PropertyValidator
    {
        public bool Validate<T, TResult>(IEnumerable<T> list, Func<T, TResult> expression)
        {
            return list.Select(expression).Distinct().Count() <= 1;
        }
    }

But the fun didn’t end there, since this was not needed in what I was working on I had to demonstrate that it worked by other means, what could those means possibly be? You guessed it, unit tests!

    [TestClass]
    public class SameValueInPropertyValidatorTests
    {
        private PropertyValidator _validator;

        [TestInitialize]
        public void Initialize()
        {
            _validator = new PropertyValidator();
        }

        [TestMethod]
        public void ReturnsTrueIfListIsEmpty()
        {
            var list = new List<string>();
            Func<string, string> expression = x => x;

            var result = _validator.Validate(list, expression);

            Assert.IsTrue(result);
        }

        [TestMethod]
        public void ReturnsTrueWhenValuesAreSameForStrings()
        {
            var list = new List<string> {"1", "1", "1", "1", "1", "1"};
            Func<string, string> expression = x => x;

            var result = _validator.Validate(list, expression);

            Assert.IsTrue(result);
        }

        [TestMethod]
        public void ReturnsFalseWhenValuesAreNotSameForStrings()
        {
            var list = new List<string> { "1", "1", "2", "1", "1", "1" };
            Func<string, string> expression = x => x;

            var result = _validator.Validate(list, expression);

            Assert.IsFalse(result);
        }

        [TestMethod]
        public void ReturnsTrueWhenValuesAreSameForKeyValuePair()
        {
            var list = new List<KeyValuePair<string, int>>
            {
                new KeyValuePair<string, int>("any1", 1),
                new KeyValuePair<string, int>("any2", 1),
                new KeyValuePair<string, int>("any3", 1),
                new KeyValuePair<string, int>("any4", 1),
            };

            Func<KeyValuePair<string, int>, int> expression = x => x.Value;

            var result = _validator.Validate(list, expression);

            Assert.IsTrue(result);
        }

        [TestMethod]
        public void ReturnsFalseWhenValuesAreNotSameForKeyValuePair()
        {
            var list = new List<KeyValuePair<string, int>>
            {
                new KeyValuePair<string, int>("any1", 1),
                new KeyValuePair<string, int>("any2", 1),
                new KeyValuePair<string, int>("any3", 456),
                new KeyValuePair<string, int>("any4", 1),
            };

            Func<KeyValuePair<string, int>, int> expression = x => x.Value;

            var result = _validator.Validate(list, expression);

            Assert.IsFalse(result);
        }

        [TestMethod]
        public void ReturnsTrueWhenValuesAreSameForEnumProperty()
        {
            var list = new List<Car>
            {
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
            };

            Func<Car, Colors> expression = x => x.Color;

            var result = _validator.Validate(list, expression);

            Assert.IsTrue(result);
        }

        [TestMethod]
        public void ReturnsFalseWhenValuesAreNotSameForEnumProperty()
        {
            var list = new List<Car>
            {
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Black},
                new Car {Color = Colors.Red},
            };

            Func<Car, Colors> expression = x => x.Color;

            var result = _validator.Validate(list, expression);

            Assert.IsFalse(result);
        }

    }

And since we were on a roll, why not remove the duplication by creating generic methods to assert the results:

    [TestClass]
    public class SameValueInPropertyValidatorTests
    {
        private PropertyValidator _validator;

        [TestInitialize]
        public void Initialize()
        {
            _validator = new PropertyValidator();
        }

        [TestMethod]
        public void ReturnsTrueIfListIsEmpty()
        {
            var list = new List<string>();
            Func<string, string> expression = x => x;

            AssertIsTrue(list, expression);
        }

        [TestMethod]
        public void ReturnsTrueWhenValuesAreSameForStrings()
        {
            var list = new List<string> { "1", "1", "1", "1", "1", "1" };
            Func<string, string> expression = x => x;

            AssertIsTrue(list, expression);
        }

        [TestMethod]
        public void ReturnsFalseWhenValuesAreNotSameForStrings()
        {
            var list = new List<string> { "1", "1", "2", "1", "1", "1" };
            Func<string, string> expression = x => x;

            AssertIsFalse(list, expression);
        }

        [TestMethod]
        public void ReturnsTrueWhenValuesAreSameForKeyValuePair()
        {
            var list = new List<KeyValuePair<string, int>>
            {
                new KeyValuePair<string, int>("any1", 1),
                new KeyValuePair<string, int>("any2", 1),
                new KeyValuePair<string, int>("any3", 1),
                new KeyValuePair<string, int>("any4", 1),
            };

            Func<KeyValuePair<string, int>, int> expression = x => x.Value;

            AssertIsTrue(list, expression);
        }

        [TestMethod]
        public void ReturnsFalseWhenValuesAreNotSameForKeyValuePair()
        {
            var list = new List<KeyValuePair<string, int>>
            {
                new KeyValuePair<string, int>("any1", 1),
                new KeyValuePair<string, int>("any2", 1),
                new KeyValuePair<string, int>("any3", 456),
                new KeyValuePair<string, int>("any4", 1),
            };

            Func<KeyValuePair<string, int>, int> expression = x => x.Value;

            AssertIsFalse(list, expression);
        }

        [TestMethod]
        public void ReturnsTrueWhenValuesAreSameForEnumProperty()
        {
            var list = new List<Car>
            {
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
            };

            Func<Car, Colors> expression = x => x.Color;

            AssertIsTrue(list, expression);
        }

        [TestMethod]
        public void ReturnsFalseWhenValuesAreNotSameForEnumProperty()
        {
            var list = new List<Car>
            {
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Red},
                new Car {Color = Colors.Black},
                new Car {Color = Colors.Red},
            };

            Func<Car, Colors> expression = x => x.Color;

            AssertIsFalse(list, expression);
        }

        private void AssertIsTrue<T, TResult>(IEnumerable<T> list, Func<T, TResult> expression)
        {
            var result = _validator.Validate(list, expression);

            Assert.IsTrue(result);
        }    

        private void AssertIsFalse<T, TResult>(IEnumerable<T> list, Func<T, TResult> expression)
        {
            var result = _validator.Validate(list, expression);

            Assert.IsFalse(result);
        }    
    }

Not exactly a break through discovery or even a coding kata but still it was a cute exercise for me to kill some time.

Would you like to share your favorite exercises or your sources of inspiration for coding research? I’d love to hear about them.

Advertisements

Just this week I blogged about how to assert the message of an expected exception and one of the things I was mentioning is how quite some people had proposed different implementations.

Today I found this post from a fellow blogger in which he talks about the MSTest Extensions library. Basically it explains how to install the NuGet package and shows a small example of how to use the ExceptionAssert method to fulfill the need of asserting the thrown exception’s message.

Unfortunately this implementation still suffers from the limitations that we discussed the last time, it can only deal with Actions so if you want to test a method with a return value or a constructor, this option will not provide a solution.

Not everything about this option is bad though, the use of generics is a nice touch so I thought I could include a couple of improvements to the solution I proposed:

    public static class AssertException
    {
        public static void Is<T>(string message, Delegate action, params object[] parameters) where T : Exception
        {
            try
            {
                action.DynamicInvoke(parameters);
                Assert.Fail(string.Format("Expected exception of type <{0}> with message <{1}> but none was thrown.", typeof(T).Name, message));
            }
            catch (Exception ex)
            {
                if (ex is AssertFailedException || ex is AssertInconclusiveException) throw;

                if (ex.InnerException == null)
                {
                    Assert.IsTrue(ex is T, string.Format("Expected exception type: <{0}> Actual: {1}", typeof(T).Name, ex.GetType().Name));
                    Assert.AreEqual(message, ex.Message, true, CultureInfo.InvariantCulture);
                }
                else
                {
                    Assert.IsTrue(ex.InnerException is T, string.Format("Expected exception type: <{0}> Actual: {1}", typeof(T).Name, ex.InnerException.GetType().Name));
                    Assert.AreEqual(message, ex.InnerException.Message, true, CultureInfo.InvariantCulture);
                }
            }
        }

        public static void Is(Exception expected, Delegate action, params object[] parameters)
        {
            try
            {
                action.DynamicInvoke(parameters);
                Assert.Fail(string.Format("Expected exception of type <{0}> with message <{1}> but none was thrown.", expected.GetType().FullName, expected.Message));
            }
            catch (Exception ex)
            {
                if (ex is AssertFailedException || ex is AssertInconclusiveException) throw;

                if (ex.InnerException == null)
                {
                    Assert.IsTrue(expected.GetType().IsInstanceOfType(ex), string.Format("Expected exception type: <{0}> Actual: {1}", expected.GetType().Name, ex.GetType().Name));
                    Assert.AreEqual(expected.Message, ex.Message, true, CultureInfo.InvariantCulture);
                }
                else
                {
                    Assert.IsTrue(expected.GetType().IsInstanceOfType(ex.InnerException), string.Format("Expected exception type: <{0}> Actual: {1}", expected.GetType().Name, ex.InnerException.GetType().Name));
                    Assert.AreEqual(expected.Message, ex.InnerException.Message, true, CultureInfo.InvariantCulture);
                }
            }
        }
    }

As you can see now the class has two overloaded methods, a generic and a non-generic versions. Also the names of both the class and the method changed so it reads a little bit better and finally both now support inherited exceptions.

This is what the use of this class will now look like:

        [TestMethod]
        public void ConstructorThrowsExceptionWhenArgumentsAreInvalid()
        {
           AssertException.Is<ArgumentNullException>("Value cannot be null.\r\nParameter name: number",
              new Func<int?, string, Foo>((num, name) => new Foo(num, name)),
              null, "any");

           AssertException.Is<ArgumentNullException>("Value cannot be null.\r\nParameter name: name",
              new Func<int?, string, Foo>((num, name) => new Foo(num, name)),
              1, string.Empty);

           AssertException.Is(new ArgumentNullException("name"),
              new Func<int?, string, Foo>((num, name) => new Foo(num, name)),
              1, string.Empty);
        }

        [TestMethod]
        public void MethodsThrowExceptions()
        {
            var firstFoo = new Foo(-5, "something");
            AssertException.Is<ApplicationException>("Number should not be negative",
               new Action(firstFoo.DoSomething));

            var secondFoo = new Foo(5, "something");
            AssertException.Is<DivideByZeroException>("Number cannot be divided by zero",
               new Action<int>(secondFoo.DoSomethingElse),
               0);
        }

        [TestMethod]
        public void FunctionsThrowExceptions()
        {
            var foo = new Foo(1, "invalid");

            AssertException.Is<InvalidCredentialException>("Authorization denied",
               new Func<bool>(foo.Validate));

            AssertException.Is<NullReferenceException>("Seriously Foo cannot be null",
               new Func<string, int?, Foo, Foo>(foo.GetNewFoo),
               "any", 3, null);
        }

As you can see the code now almost reads as regular English. It is still more verbose than the attribute option but we discussed the advantages and disadvantages of both approaches on the previous post.

So a couple of conclusions that I can get are that even though we may have a good solution for a particular problem we can always find inspiration and ideas to improve those solutions and we should always be humble enough to realize that our solutions could be improved, no matter how much we might like them.

The same as last time here you have several options to assert the message of exceptions in your unit tests. Use the one you consider the most appropriate. Happy coding.

If you do a quick google search you will realize a lot of people out there have the need to be able to unit test that a piece of code throws an exception with a specific message. Unfortunately the ExpectedExceptionAttribute attribute does not provide this feature. It does have a “message” parameter but its use is to define the message the developer will see when the test fails.

All the people with this need, myself included, have searched long and hard for a way to implement an attribute with this functionality or, at the very least, a way to execute this kind of test reliably and in a way that it can be reused consistently for each possible case.

Most implementations I have found are different flavors of catching the exception and comparing the type and message to an expected one, but they are limited in the number or type of parameters, or on the return type they support. I did once find the implementation of an attribute but was a little disappointed since I thought it was too much code for something as simple as the objective at hand. Let me be very clear about the fact that I am NOT saying this is a bad option nor am I discouraging its use in any way or form. I am only saying that, in my very personal opinion, it is too much code for something so simple and, it is code that you should understand how it works since you might have the need to maintain it.

So because of this I came up with another implementation by using delegates which is smaller than the attribute one and supports both actions and functions with as many parameters as needed. It does have the disadvantage though that its use might be a little cryptic. I always strive for code readability so decorating the test method with an attribute may be a little better. Here is the code, some examples on its use and, for completeness, a Foo class to test it:

This is the code that we are interested in:


public static class CustomAssert
{
   public static void IfExceptionIs(Exception expected, Delegate action, params object[] parameters)
   {
      try
      {
         action.DynamicInvoke(parameters);
         Assert.Fail(string.Format("Expected exception of type <{0}>; with message <{1}> but none was thrown.", expected.GetType().FullName, expected.Message));
      }
      catch (Exception ex)
      {
         if (ex is AssertFailedException || ex is AssertInconclusiveException) throw;

         if (ex.InnerException == null)
         {
             Assert.AreEqual(expected.Message, ex.Message, true, CultureInfo.InvariantCulture);
             Assert.AreEqual(expected.GetType(), ex.GetType());
         }
         else
         {
             Assert.AreEqual(expected.Message, ex.InnerException.Message, true,  CultureInfo.InvariantCulture);
             Assert.AreEqual(expected.GetType(), ex.InnerException.GetType());
         }
      }
   }
}

This would be the testing Foo class:

public class Foo
{
   private readonly int? _number;
   private readonly string _name;

   public Foo(int? number, string name)
   {
      if(!number.HasValue) throw new ArgumentNullException("number");
      if(string.IsNullOrEmpty(name)) throw new ArgumentNullException("name");

      _number = number;
      _name = name;
   }

   public void DoSomething()
   {
      if(_number < 0) throw new ApplicationException("Number should not be negative");
   }

   public void DoSomethingElse(int dividend)
   {
      if(dividend == 0) throw new DivideByZeroException("Number cannot be divided by zero");
   }

   public bool Validate()
   {
      if(_name == "invalid") throw new InvalidCredentialException("Authorization denied");
      return true;
   }

   public Foo GetNewFoo(string newName, int? newNumber, Foo oldFoo)
   {
      if(oldFoo == null) throw new NullReferenceException("Seriously Foo cannot be null");
      return new Foo(newNumber, newName);
   }
}

And this is how it would be used:

[TestMethod]
public void ConstructorThrowsExceptionWhenArgumentsAreInvalid()
{
   CustomAssert.IfExceptionIs(new ArgumentNullException("number"),
      new Func<int?, string, Foo>((num, name) =>; new Foo(num, name)),
      null, "any");

   CustomAssert.IfExceptionIs(new ArgumentNullException("name"),
      new Func<int?, string, Foo>((num, name) => new Foo(num, name)),
      1, string.Empty);
}

[TestMethod]
public void MethodsThrowExceptions()
{
   var firstFoo = new Foo(-5, "something");
   CustomAssert.IfExceptionIs(new ApplicationException("Number should not be negative"),
      new Action(firstFoo.DoSomething));

   var secondFoo = new Foo(5, "something");
   CustomAssert.IfExceptionIs(new DivideByZeroException("Number cannot be divided by zero"),
      new Action<int>(secondFoo.DoSomethingElse),
      0);
}

[TestMethod]
public void FunctionsThrowExceptions()
{
   var foo = new Foo(1, "invalid");

   CustomAssert.IfExceptionIs(new InvalidCredentialException("Authorization denied"),
      new Func<bool>(foo.Validate));

   CustomAssert.IfExceptionIs(new NullReferenceException("Seriously Foo cannot be null"),
      new Func<string, int?, Foo, Foo>(foo.GetNewFoo),
      "any", 3, null);
}

To have the complete picture here are some snippets on how would the tests look like if we were to use the custom attribute:


[TestMethod]
[ExpectedExceptionWithMessage(typeof(ArgumentNullException), "name")]
public void ConstructorThrowsExceptionWhenNameIsEmpty()
{
   new Foo(1, string.Empty);
}

[TestMethod]
[ExpectedExceptionWithMessage(typeof(ApplicationException), "Number should not be negative")]
public void MethodThrowsExceptionWhenNumberIsNegative()
{
   var foo = new Foo(-5, "something");
   foo.DoSomething();
}

Another thing to note is that the implementation I am proposing looks for an inner exception since sometimes the real problem might be hiding in there and the attribute one supports inherited exceptions. Both options could easily be added in either one.

So there you have it, two options to assert the message of an expected exception. Use the one you consider best for you, your team and your project and may your unit tests save you from grief and maintenance nightmares.

In the twelve years I’ve been developing software I’ve seen quite a few methods, classes, subroutines, scripts, among others. A statement that has been true ever since day one of my development years is that I have spent more time reading code than writing it and I’m sure I don’t have to tell you about some of the horrors I’ve seen during this time. Thinking about this, I’ve come to realize that after so many years of hearing and reading about best practices, self-documented code, small classes and methods, single responsibility purpose, and quite some others nifty concepts it’s amazing how you can still find 500 or more lines of code methods, huge classes that have multiple responsibilities, tightly copuled and low cohesive objects and all sort of development nightmares that make the code difficult to read and maintain.

Surely there is not a single developer who has not written a method only to come back to it some time later and not being able to understand what on earth is it doing, or at the very best to have to spend quite some time figuring it out. And of course that is even more true when we stumble upon a piece of code written by someone else.

With legions of excellent developers all over the world, I truly believe that there can never be enough talk about ways of trying to improve the readability and ease of maintainability of code so, in that tone, I would like to post here a very small demonstration of a piece of code we had at our current project that was, well quite bad, and how it became much more readable after doing some very simple refactoring.

private void SetPermissionToAdjustOrCancell(CustodyTicketDto custodyTicketDto)
{
  var userRole = PortalInternalService.GetRolesforUser(UserSettings.Current.UserId, UserSettings.Current.CompanyId);
  bool canCancelAdjustTicket = false;

  foreach (RoleDto role in userRole)
  {
     if (role.RoleName == Roles.FIELD_OPERATOR_RECEIPT && Activity.ToUpper() == “RECEIPT”)
       canCancelAdjustTicket = true;

     if (role.RoleName == Roles.FIELD_OPERATOR_DELIVERY && Activity.ToUpper() == “DELIVERY”)
       canCancelAdjustTicket = true;
  }

  _view.IsUserAllowedToAdjustOrCancel = canCancelAdjustTicket &&
    (
     (custodyTicketDto.IsCancellable.HasValue && custodyTicketDto.IsCancellable.Value) ||
     (custodyTicketDto.IsAdjustable.HasValue && custodyTicketDto.IsAdjustable.Value)
    );
}

Now this method is by far not the worst anybody has ever seen, but it’s bad enough to illustrate what we should be after. As you can see it has quite a few lines of code, there are several things going on at different levels of abstraction and you need a few moments to analyze each conditional within the method to understand what each one does.

So the first thing we had to do was to write a few unit tests just to make sure we were not breaking anything and once that was set we started breaking up this creepy method into something much more manageable and quite more readable. The end result, at least for now, was this:

private void SetPermissionToAdjustOrCancell(CustodyTicketDto custodyTicketDto)
{
   var userRoles = PortalInternalService.GetRolesforUser(UserSettings.Current.UserId, UserSettings.Current.CompanyId);

   _view.IsUserAllowedToAdjustOrCancel = IsUserInRoleThatAllowsCancelOrAdjust(userRoles) && IsTicketAdjustableOrCancellable(custodyTicketDto);
}

private bool IsUserInRoleThatAllowsCancelOrAdjust(IEnumerable userRoles)
{
   bool canCancelAdjustTicket = false;

   foreach (RoleDto role in userRoles)
   {
      if (IsReceiptRoleAndReceiptActivity(role) || IsDeliveryRoleAndDeliveryActivity(role))
         canCancelAdjustTicket = true;
   }
   return canCancelAdjustTicket;
}

private bool IsReceiptRoleAndReceiptActivity(RoleDto role)
{
   return role.RoleName == Roles.FIELD_OPERATOR_RECEIPT && Activity.ToUpper() ==
“RECEIPT”;
}

private bool IsDeliveryRoleAndDeliveryActivity(RoleDto role)
{
   return role.RoleName == Roles.FIELD_OPERATOR_DELIVERY && Activity.ToUpper() ==
“DELIVERY”;
}

private bool IsTicketAdjustableOrCancellable(CustodyTicketDto custodyTicketDto)
{
   return (custodyTicketDto.IsCancellable.HasValue && custodyTicketDto.IsCancellable.Value) ||
(custodyTicketDto.IsAdjustable.HasValue && custodyTicketDto.IsAdjustable.Value);
}

Now I am very well aware that this method could still be improved, for example the loop in the IsUserInRoleThatAllowsCancelOrAdjust method could very well be replaced by linq queries or that the IsTicketAdjustableOrCancellable could be broken in two methods, but the point is that now someone who has never seen this code will have very little trouble if at all to understand what each method is doing, and without having to add a single comment !!!!

I do not mean to say that this is THE way to go but at least it has been working for us. We’ve had a few new developers say that it is so simple to understand this kind of code and add features or fix defects in it so, if you think this kind of style could be beneficial I encourage you to give it a try and decide if it could prove to be usefull in the long run.