James McCaffrey

At last! I have been waiting for a built-in BigInteger data type for .NET ever since .NET 1.0 was released. The .NET Framework version 4.0 adds this type in a new System.Numerics namespace. The BigInteger type allows arbitrarily large integers. This is useful for a wide range of mathematical functions including functions which compute the number of permutations of n items, and the number of combinations of n items taken k at a time (where order does not matter) -- two fundamental computations in software testing. For example, the number of permutations of n items is just Factorial(n) = n * (n-1) * (n-2) * . . . 1.  If you code a naive version of Factorial() using type long, the largest value which can be represented is +9,223,372,036,854,775,807 which seems pretty big but this will only deal with a result of up to Factorial(20). For example:

 

static long FactorialBad(int n)
{
  long answer = 1;
  if (n < 0) throw new Exception("xxx");
  if (n == 0) return 1;

  for (int i = 1; i <= n; ++i)
    answer *= i;

  return answer;
}

 

will compute Factorial(20) correctly but Factorial(21) returns -4,249,290,049,419,214,848. The function loop hits long.MaxValue and then silently wraps around to long.MinValue (a negative number) and continues and ends up negative. But:

 

static BigInteger FactoriaBigInt(int n)
{
  BigInteger answer = 1;
  if (n < 0) throw new Exception("xxx");
  if (n == 0) return 1;

  for (int i = 1; i <= n; ++i)
    answer *= i;

  return answer;
}

 

can deal with very, very large values. By the way, in many cases using a lookup table to perform factorial computations is a much better approach than using the approach I showed here.

Over the past few days I've been looking at testing WCF services using a network socket based approach. I got a proof-of-concept demo program up and running. As usual, there were several glitches along the way. The key to resolving most of these glitches was to examine network traffic between a WCF service and a client, using a traffic examination tool. I used Fiddler, which has come in handy many times. See screenshot below. In a larger perspective, software testing is often all about understanding some software system. Once a system is fully understood, testing the system manually or programmatically usually comes pretty easily (relatively anyway). I am writing up an article on the technique of testing WCF services using sockets for MSDN Magazine and I'm happy with the way it is going.

 

Suppose you are testing a WCF (Windows Communication Foundation) service. In some situations you may want to view the low level traffic between a WCF client and the service. The easiest way to do this in general is to use a network analyzer such as netmon and capture the traffic as the client sends a request and receives a response. However in some test automation situations you may want to programmatically capture WCF traffic. There are several good blog posts on this topic but I couldn't find a complete end-to-end example so I experimented and came up with an example of how to do this.

 

First, let's assume we have a WCF service name MathService running in either a Console host, or in a Windows Service host, or in an IIS host:

 

 

To programmatically capture WCF traffic you can first create a Console Application client like so:

 

 

Next you can add two classes to the client like so:

 

And then you can wire up the two classes in the client like so:

 

 

When you execute the Console Application client program, WCF traffic will be echoed to the shell as demonstrated in the partial screenshot below.

 

I have been looking at Silverlight lately and have been investigating how to create UI test automation for Silverlight applications. As far as I can tell so far, it looks like there are two main approaches. First, you can use the Microsoft UI Automation (MUIA) library to create C#, shell-based test automation. A second approach is to use JavaScript-to-Silverlight interoperability and create browser-based test automation. I haven't tried ether approach but I'm fairly confident I could work out the details. A third possibility is to somehow use Silverlight technology to create UI test automation for a Silverlight application. I'm not sure how this would work, or if the technique is even possible, but the idea sounds interesting.

The .NET Framework version 4.0 supports a new programming language feature called variant methods. Let me cut to the chase and state I think variant methods are an example of solutions in search of a problem, but they're fascinating anyway. So what are contravariant and covariant methods, and how do you test them? In order to test variant methods you need to understand what they are. In short, MSDN Library documentation states that contravariance is the ability to use a less derived type, and covariance is the ability to use a more derived type than that originally specified. My initial reaction was pretty much WFH (what the heck). I couldn't entirely follow the MSDN examples so I played around with some code myself. After some experimentation, I believe that the scenario where contravariance and covariance are most likely to be used is when you 1.) have a generic interface, and also 2.) have a base class which implements the generic interface, and also 3.) a second class which is derived from / inherits from the base class. For example, suppose you have some generic interface IConsoleDisplayable<T>:

 

public interface IConsoleDisplayable<T>
{
  . . .
}

and a class Person which implements IConsoleDisplayable<>, and also a class Employee which is derived from class Person. Without contravariance and covariance the following code does not work:

 

IConsoleDisplayable<Person> p = new Person("Smith", "Chris"); // OK
. . .
IConsoleDisplayable<Employee> e = p; // error

 

and requires an explicit cast like this:

 

IConsoleDisplayable<Employee> e = (IConsoleDisplayable<Employee>)p; // OK

 

But if you declare the generic interface as contravariant by adding the "in" keyword like this:

 

public interface IConsoleDisplayable<in T>
{
  . . .
}

 

then the code above (without an explicit cast) compiles. Well this is just plain psycho on a variety of levels and seems like the C# language team had way too much time on their hands. Just because you can create some new language feature doesn't necessarily mean you should. (Of course, there's no reason why application or system developers have to use variant methods). In my opinion, the advantage gained by eliminating an explicit cast is not worth the additional complexity of a contravariant interface. But it's an interesting language concept for sure.