Windows Live Writer Beta 2

This post was created with the recently released Windows Live Writer Beta 2.  It supports multiple providers out of the box, it works with WordPress, Windows Live Spaces, and TypePad.  However, you can expand it by using Provider Customization API.  That exactly is what Scott Hanselman did for DasBlog.  Read Scott’s Windows Live Writer Beta 2 – DasBlog and the Customization API post for more details.

 

As I created this post, I had one problem when I tried to open my existing posts from WordPress.  I got ArgumentOutOfRangeException.

Addition to Julian Hidalgo blog on TestSequence attribute.

MbUnit contributor, Julian Hidalgo, blogs about using TestSequence attribute. He points out the typical mistake people have when they try to use this attribute for the first time. When I tried to use it for the first time, I also used TestFixture attribute instead of ProcessTestFixture one.

Julian did a good job of demonstrating how to use it. I would like to add that when you put your tests in ProcessTestFixutre, MbUnit will combine all your tests into one big test. The name of the big test will be all your test names separated by a period in the order specified by TestSequence attribute. For instance, if you have a fixture like the one bellow (borrowed from Julian’s blog), your big test name will be SequenceAttributeTest.Test1.Test2.

    [ProcessTestFixture]

    public class SequenceAttributeTest

    {

        private int i = 0;

        [Test]

        [TestSequence(2)]

        public void Test2()

        {

            i += 1;

            Assert.AreEqual(i, 2);

        }

        [Test]

        [TestSequence(1)]

        public void Test1()

        {

            i += 1;

            Assert.AreEqual(i, 1);

        }

    }

Another thing I’d like to mention is that if one of the tests fails, the execution stops. It means that no test will be executed after failed test.  If in example above Test1 fails, Test2 will not be run.

Unfortunately, you cannot use RowTest in ProcessTestFixutre.

TestDrivet.NET is the most usefull tool in Visual Studio.

I’ve been using TestDriven.NET for more than year. And I have to tell you that it’s probably the most useful tool for me. To be able to Run Test(s) or Build the project just by right clicking on the source code is time saving.

Let’s look at the test fixture bellow.

namespace MyFixtures
{
   [TestFixture]
   public class FixtureOne
   {
      [Test]
      public void Test1()  
      {
         Assert.IsTrue(true);
      }  

      [Test]
      public void Test2()
      {
         Assert.IsTrue(true);
      }  

      [Test]
      public void Test3()
      {
         Assert.IsTrue(true);
      }
  }
}

Here are some thing I learned just by trying.

This one is probably obvious.

Click right button inside Test1 method and choose Run Test(s), only Test1 test will be run.

Here are some things that took me awhile to discover:

Click right button just bellow public class FixtureOne, and all three tests, Test1, Test2, and Test3, will be run.

Click right button just bellow namespace MyFixtures, and all the tests for MyFixtures namespace will be run.

I build my projects now jut by clicking right button on the source file and select Build. I just wonder why Microsoft doesn’t add build command in Visual Studio context menu.

How cool to have Reflector in your context menu. I mostly use it by expanding References in Solution Explorer clicking right button on the reference I want to reflect; something like System.Data for instance. It loads that assembly just by clicking on Go To Reflector item in the context menu.

And it’s not all. I’m sure there are many ways you’re using this tool that I haven’t discovered yet. Share with me, I want to learn from you.

MbUnit: Arrays with RowTest

At my place of work some people were surprised that it’s possible to put array of values in Row attribute. I hope that some people can find this information useful.

[RowTest]
[Row(new string[] { "0", "4"}, new int[] {0, 4})]
public void CompareArrays(string[] strArr, int[] intArr)
{
   int len = strArray.Length;
   Assert.AreEqual(len, intArr.Length);
   for (int i = 0; i < len; i++)
      Assert.AreEqual(strArr[i], intArr[i].ToString());
}

I often use arrays to create an IEnumerable type like List<T>.

[RowTest]
[Row(new string[] { "str1", "str2" }, 2)]
public void ListTest(string[] strArray, int length)
{
   List<string> strList = new List<string>(strArray);
   Assert.AreEqual(length, strList.Count);
}

There’s one known problem with using arrays. You’ll get a compile error like this one “An attribute argument must be a constant expression, typeof expression or array creation expression” if an array is only parameter in Row attribute. Code below will not compile.

[RowTest]
[Row(new string[] { "str1", "str2" })]
public void NoComplie(string[] strArray)
{
}


I use this feature of MbUnit a lot. 

Empower yourself with MbUnit.

MbUnit 2.4 RTM: Now you can use Decimals in Row attributes.

I switched from NUnit to MbUnit because of RowTest feature. You can read more about RowTest from Ben Hall’s post. I’ve been using RowTest(s) a lot. However, before MbUnit 2.4 RTM, it was impossible to use decimals in Row attribute. If you try to use code below with MbUnit version prior 2.4 RTM, you’ll get an ArgumentException with “Object of type ‘System.Double’ cannot be converted to type ‘System.Decimal’.” message.

[RowTest]
[Row(10.2, 2.5)]
public void DecimalTest(decimal x, decimal y)
{
  Assert.AreEqual(12.7, x + y);
}

The reason the exception happens is because for CLR, the decimal is not primitive type even if it’s for C#. Basicaly you cannot use decimal type with attributes.
MbUnit team was able to work around this limitation, so now you can safely use decimal in your Row attribute. However, there’re some cases that still not going to work even with the latest version. Here’s the example.

[RowTest]
[Row(21.5, 5.21, 4.1266794625719769673704414587)]
public void Div(decimal x, decimal y, decimal result)
{
  Assert.AreEqual(result, x / y);
}

If you try to run this test, you’ll see this message:

Equal assertion failed: [[4.12667946257198]]!=[[4.1266794625719769673704414587]]

Wait a second. Why do I see 4.12667946257198 when I explicitly typed 4.1266794625719769673704414587 for the third paramater in the Row attribute? The reason is the attributes don’t support decimals and the parameter was converted to double type.
MbUnit team haven’t find a solution for this limitation yet but they gave you a pretty good workaround. You can make this test work if you surround 4.1266794625719769673704414587 with double quotes.

This test should work with no problems at all.

[RowTest]
[Row(21.5, 5.21, "4.1266794625719769673704414587")]
public void Div(decimal x, decimal y, decimal result)
{
  Assert.AreEqual(result, x / y);
}


MbUnit 2.4 RTM is Here

Get new version of MbUnit 2.4 from here. If you’re using NUnit, try MbUnit and you’ll never go back to NUnit.