# Thursday, July 15, 2004

The MbUnit Console Runner Application has undergone a major "plastic surgery" to prepare the next release of MbUnit. The new features are :

  • Report output to Xml, Html or Text, or a combination of those. The output directory of the reports can also be specified in the command line,
  • Filtering of the fixture by
    • Namespace,
    • Type full name,
    • Category,
    • Author name,
    • Importanc
  • Each of the filter can be multiple, i.e. you can filter multiple namespace. The different filters are combined using a AND operator.
  • The help is showed each time it is called (I have copy/pasted) the output of
  • The parsed parameters are displayed before testing starts to give you more information, 

The output of console runner as it is in the CVS:

MbUnit 2.15.1657.17890 Console Application
Author: Jonathan de Halleux
Get the latest at   http://mbunit.tigris.org
------------------------------------------
    /report-folder:                     short form /rf  Target output folder for the reports
    /report-type:{Xml|Html|Text}        short form /rt  Report types supported: Xml, Html, Text
    /filter-category:                   short form /fc  Name of the filtered category
    /filter-author:                     short form /fa  Name of the filtered author name
    /filter-type:                       short form /ft  Name of the filtered type
    /filter-namespace:                  short form /fn  Name of the filtered namespace
    /verbose[+|-]                       short form /v   Return a lot of information or not...
    @file                             Read response file for more options
    files
------------------------------------------
-- Parsed Arguments
Files:
        MbUnit.Tests.dll
Report folder:
Report types:
Filter Category:
Filter Author:
Filter Namespace:
Filter Type:
Verbose: False

ps: Filtering is a brand new feature of MbUnit that I will discuss in another thread.

posted on Thursday, July 15, 2004 10:28:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]
# Wednesday, July 14, 2004

An installation tutorial "for Dummies" is available at http://www.dotnetwiki.org/Default.aspx?tabid=55

posted on Wednesday, July 14, 2004 1:09:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

With all those addins poping out on the blog, maintaining the files was becoming quite messy. In order to simplify a lot of things, I have upgraded my old www.dotnetwiki.org web site to DotNetNuke 2.1.2 with the following components:

  • Issue tracker for the Reflector Addins, please use it instead of sending the bugs to Lutz,
  • Forums, what thread can be watched by emails and news feed,
  • Download section, where the files are stored and link remain permanent

See you seen on www.dotnetwiki.org .

posted on Wednesday, July 14, 2004 12:30:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]
# Tuesday, July 13, 2004

After this afternoon crash of the blog, it is time to get back to some fun activities...and today code coverage is the program. I will be using NCover (gotdotnet) but other tools could apply also.

There is one thing that strikes me with code coverage: there is almost no efficient tool to visualize coverage (I'm leaving aside Team System for now). Usually the framework that compute the coverage already have a big job to do with computing it, and the visualization is somehow "left to the user". It seems to me that this part of the job is not trivial also because of the quantity of information that has to be processed: an assembly can have hundreds of types, thousands of methods. This motivates the introduction of some new...  Reflector Addins for code coverage visualization.

Coverage in a TreeMap

A natural way of visualizing coverage is to use the TreeMap that I was previously using for the Type TreeMap addin.With some minor modifications, we have the following result: the figure shows the test coverage of NCollection project (green is fullly covered, red is not covered).

NCover and Reflector

The most difficult/annoying part of this work was to create the bridge between NCover and Reflector, because of slight difference in the way name, assembly and modules are named.

posted on Tuesday, July 13, 2004 9:02:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [10]

Following the PropertyGrid and the XmlSerialization addin, this addin displays the control classes inside Reflector.

The addin is desesperately simple: if the selected class inherits from System.Windows.Forms, the addin instanciate it and adds it to the window.

posted on Tuesday, July 13, 2004 1:39:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

This is a preview of a new Reflector addin to well let you search for Program Patterns in your assemblies. The addin is mainly an adaptation to .Net of the article from Santany Paul and Atul Prakash, "A Framework for Source Code Search using Program Patterns".

What are Program Patterns ?

In their article, the authors use a pattern language to specify high-level patterns for making queries on the source code. It smells like regular expression but it operates on statements and expression instead of strings. The basic pieces of the pattern languages are:

  • # describes any expression,
  • @ describes any statement,
  • more to come here...

More specific patterns, like if, while, throw,  are also defined. In fact, for each interface of the Reflector.CodeModel namespace, a corresponding pattern class is needed. Let's illustrate this with a simple example of query: Find all occurence of a if followed by a throw statement.
In the original paper notation, the pattern is defined as follows:

if (#) throw #;

Of course this will have to change a bit for C#.

C# implementation

In my implementaiton, the IPattern interface defines a Program Pattern:

public interface IPattern
{
    bool Match(Object target);
}

The interface is intentionaly simple to enable great extensibility. This interface is then specialized for IStatement, IExpression, IBlockStatement, etc.. For example, the pattern to match a throw statement will be implemented as follows:

public class ThrowExceptionStatementPattern : StatementPattern
{
    // pattern for the expression that is throwed. Pats is a helper class
    private ExpressionPattern expression = Pats.AnyExpression;
    ...

    public override bool Match(IStatement statement)
    {
        // trying to cast statement to IThrowExceptionStatement
        IThrowExceptionStatement th = statement as IThrowExceptionStatement;
        // did not cast, no match
        if (th==null)
            return false;
        // expression did not match, no match
        if (!this.Expression.Match(th.Expression))
            return false;
        // we have a match!
        return true;
    }
}

To ease up things, a helper class containing static methods (Pats) takes care of creating those objects.

Implementing the example

Implementing the example is now just a matter of putting the pieces together. We need a pattern for the if, one for the throw and a pattern that will recurse in all the statements:

// provided by Reflector
IMethodDeclaration visitedMethod = ...
// if pattern
ConditionStatementPattern ifthen = Pats.If();
// setting the Then pattern
// StatementInBlock says the pattern should be in the IBlockStatement
// Pats.Throw() returns a ThrowExceptionStatementPattern 
ifthen.Then = Pats.StatementInBlock(Pats.Throw());
// a pattern that will recurse all the statements
RecursiveStatementPattern rec = Pats.Recursive(ifthen);

// launching the seach
rec.Match(visitedMethod.Body);

Testing the example

The above pattern has been applied to the following class where 2 methods match the pattern, and 2 do not match it:

public class CodeMatchingTest
{
    public void If(bool arg)
    {
        Console.WriteLine("This method has a if");
        if (arg)
            Console.WriteLine("arg is true");
        else
            Console.WriteLine("arg is false");
    }
    public void Throw()
    {
        throw new Exception();
    }
    public void IfThrow(bool arg)
    {
        if (arg)
            throw new Exception();
    }
    public void IfThrowHiddenInsideWhileLoop(bool arg)
    {
        int i = 0;
        while(i<10)
        {
            if (i>5)
                throw new Exception();
            Console.WriteLine(i.ToString());
        }
    }
}

And the result in Reflector is displayed below. As expected, IfThrow and IfThrowHiddenInsideWhileLoop have matched the pattern.

posted on Tuesday, July 13, 2004 1:38:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]

Jamie Cansdale (NUnitAddin) has recently started to use the SSCLI tests to verify the output of Reflector.

"The Shared Source Common Language Infrastructure 1.0  is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification. This implementation builds and runs on Windows XP, the FreeBSD operating system, and Mac OS X 10.2." says the description. If you download this file, you will see that it ships with tons of tests that are used to test the CLI implementation. Each one of the test classes is to be compiled into a console application that returns 0 if successful, 1 otherwise.... Could we harness those test using a test framework ?

First try: all tests in one assembly

Since each fixture is designed to be compiled as a console, we just need to look for classes with a static Main method, load them and execute the main method. This is rather optimistic because it assumes that you can compile all the tests into a single assembly and then load, which is not true because a lot of classes are duplicated and clashes. Anyway, I managed to load some of them "just for fun":

Second try: dynamic compliation

Jamie was ahead of me and had already the solution. He designed a bunch of helper classes that dynamically load the files, compile, and execute them. This combined to a CodeSmith template that would generate a huge fixture (one case per file), he had this harnessed for NUnit. Jamie is kind of "shy" (sorry Jamie) and does not want to write about the amazing stuff he is doing with testing. So if you want to know how he managed to wrap up SSCLI tests in NUnit in a record time, give him a shout ! 

That's all for today, I'll have to modify MbUnit to integrate Jamies work... 

posted on Tuesday, July 13, 2004 1:37:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

How do you handle the inclusion of examples into your C# documentation ? If you've been asking yourself this question, here's a quick tip for automatic example inclusion.

Let's start with an example. Consider the following dummy class MyClass:

public class MyClass
{
 ...
}

We hapilly write anexample for the MyClass class in a separate xml file (say Doc.xml):

<doc>
  <examples>
    <example name="example1">
       public class MyLibrary
       {
           public static Main(string[] args)
           {
               MyClass mc = new MyClass();
           }
       }
    </example>
  </examples>
</doc>

Now the way Visual Studio suggests uses to include the example is to use the include tag with a XPath expression similar to this:

//< include file='Doc.xml' path='example[@name="example1"]' />

This is fine but it can break easily.Moreover, assuming that you have a lots of examples, you may miss some example that could be integrated into the documentation.

A much better solution is to use the power of XPath. In fact, what we want to include is all the examples that involve the MyClass class, which in XPath translates to: contains(descendant-or-self::*,'MyClass'):

/// <include 
///     file='MyLibrary.Doc.xml' 
///     path='//example[contains(descendant-or-self::*,"MyClass")]'
/// />

That's it. Instead of using name=... you stop worrying and let XPath find the proper examples for you.

posted on Tuesday, July 13, 2004 1:36:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

I was waiting for this moment for a long time: we have matrix algebra package for .NET!

dnAnalytics home page: http://www.dnanalytics.net/

posted on Tuesday, July 13, 2004 1:36:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]

From Benjamin blog;

BOF001: James Newkirk on Integrating Unit Testing into the Software Development Lifecycle.

James Newkirk leading the Unit Testing BoFJames Newkirk lead a Birds of a Feather session on Test Driven Development.  The room was packed to the rafters, showing that Unit Testing is starting to reach a critical mass.  Here are my notes on the discussion from the session which covered how to write tests, how to use tests against legacy systems, how to test against the database and many other topics.

Should we write test code against interfaces or something more abstract than the implementation?
James mentioned that MbUnit is a tool that allows you to test against an interface.  The question was whether you should create interfaces that enable tests to be written against them in case further implementations were created in future.  James' attitude was that this might result in wasted work ('you aint gonna need it') since you may not need it, or may not need it now.  Instead, abstract things out when you need them - don't create an interface just to test it.

James also said that an interface is not a good example of the contract of what is being done - it is the name of the method with input and outputs, but does not reflect how the method reacts to the input. James writes tests that show the real interaction between someone that calls the code and what it produces.

I must say I'm disapointed to have missed TechEd Amsterdam and this session (It's only a couple hour from Brussels). Aaaaargghhh!

posted on Tuesday, July 13, 2004 1:35:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]