Collected from http://sendhil.spaces.live.com/blog/cns!30862CF919BD131A!154.entry

From a rocket scientist's diary ;-)

TDD is like paying using cash!!

Good judgement is the result of experience ... Experience is the result of bad judgement. — Fred Brooks

http://davidhayden.com/blog/dave/archive/2006/12/21/QueryExpressionsAnonymousTypesLambaExpressions.aspx

C# 3.0 Features - C# 3.0 Examples - Query Expressions - Anonymous Types - Lamba Expressions - Extension Methods

by David Hayden ( Microsoft MVP C# ), C# 3.0 Tutorials and Features

Awhile back I talked about Extension Methods in C# 3.0 and how LINQ uses them to provide additional methods to classes implementing IEnumerable<T> for querying purposes.

Hence, you can use LINQ, for example, to query a class of List<Customer> because List<T> implements IEnumerable<T>. Let's mind walk through this :)

Automatically Implemented Properties ( Compiler Feature )

Creating a Customer Class using Automatically Implemented Properties in the Orcas C# 3.0 Compiler gives you the following code:

public class Customer {

    public int Id { get; set; }

    public string Name { get; set; }

    public string City { get; set; }

    public Customer() {}

}

Object and Collection Initializers

You can then use the new C# 3.0 Collection and Object Initializers to create the List<Customer> class:

List<Customer> listOfCustomers =

        new List<Customer> {

            { Id = 1, Name="Dave", City="Sarasota" },

            { Id = 2, Name="John", City="Tampa" },

            { Id = 3, Name="Abe", City="Miami" }

        };

Query Expressions

And then you can query the list of customers using query expressions:

var query =

    from c in listOfCustomers

    where c.City == "Sarasota"

    select new {c.Name,c.City};

Implicity Typed Local Variables and Anonymous Types

 Pulling apart the query expression above shows us a couple of new features in C# 3.0:

• The var keyword used above signals the use of Implicitly Typed Local Variables for variable assignment
• new { c.Name, c.City } is an example of Anonymous Types so we don't have to declare the new type.

Query Expression Translation

But, as I mentioned before, this is just a bit of syntatic sugar, because the query expression gets translated using Query Expression Translation into extension methods that are invoked behind the scenes. The .Where and .Select Methods are extension methods of IEnumerable<T>:

var query = listOfCustomers

                .Where(c => c.City.Equals("Sarasota"))

                .Select(c => new {c.Name, c.City});

Lambda Expressions

Lambda Expressions are shown above to ease the pain of typing the very verbose anonymous delegates:

c => c.City.Equals("Sarasota")

avoids

delegate(Customer c) {

    return c.City.Equals("Sarasota");

}

Extension Methods

As with all Extension Methods, they are sitting somewhere in a static class as static methods. In this case, System.Query.Sequence. The above can also be written as:

var query = Sequence

                .Where(listOfCustomers, c => c.City == "Sarasota")

                .Select(c =>new { c.Name, c.City });

Query Execution

And, of course, this query does not execute until it is enumerated:

var sarasotaCustomers = query.ToList();

Also Refer

http://davidhayden.com/blog/dave/category/58.aspx?Show=All

Introducing Internet Information Services (IIS) 7.0

Pasted from <http://www.devx.com/enterprise/Article/34619?trk=DXRSS_LATEST>

icrosoft recently rolled out its next-generation operating system (OS), Windows Vista. One of the core Vista components is a new version of Microsoft's web server—Internet Information Services version 7.0 (IIS 7.0). IIS 7.0 will also be part of Windows Server "Longhorn", which is expected to ship in mid 2007. This article provides a developer-centric look at IIS 7.0.

IIS in Recent Times

If you think back a few years to IIS 5.0, the future for Microsoft's web server looked rather bleak, because network-savvy worms such as Nimda, Code Red, Code Red II, and their variants were affecting thousands of computers worldwide, and rapidly damaging IIS's reputation. Microsoft introduced the IIS lockdown tool to combat these exploits and, with the release of IIS 6.0, made "locked down" mode settings the default at installation, which helped minimize such security problems, and helped IIS 6.0 recapture a major part of trust that IIS 5.0 lost. No major security disasters have been reported since the release of IIS 6.0.

A recent market survey (Netcraft Web Server Survey—April 2007 ) indicated that Microsoft's IIS has a 31.13 percent market share, which places it in second position behind the open source Apache Web Server. Another survey by Port80 Software that takes Fortune 1000 companies into consideration reports that IIS has overtaken Apache among Fortune 1000 sites.

Now, Microsoft is looking to consolidate IIS 7.0's position as a secure and robust web server.

IIS 7.0 Core Components

IIS 7.0's core components differ from those in IIS 6.0. IIS 7.0 is made up of three core components as illustrated in Figure 1.

Author's Note: The screen images shown in this article are from a system running Windows Server "Longhorn", August CTP (Build 5600)—some of the features may change before the product is released in its final form.

·         Protocol Listeners: A protocol listener listens to specific requests based on a specific protocol and sends the request to the IIS worker process for processing. Protocol listeners provided with IIS 7.0 include HTTP.sys, NET.TCP, NET.MSMQ and NET.PIPE.

·         WWW Service: This service acts as a listener adapter for the HTTP.sys protocol listener and monitors the HTTP requests.

·         Windows Activation Service (WAS): WAS is a new service in IIS 7.0 that manages application pool configuration and worker processes. In IIS 6.0, this responsibility was part of the WWW Service. The shift to a separate core component ensures that developers can use the same process model and configuration for both HTTP and non-HTTP based sites. It is possible to configure the other three protocol listeners (NET.TCP, NET.MSMQ and NET.PIPE) using WAS.

For example, when the NET.TCP protocol listener is configured it listens for TCP requests. WAS can also be used to host a Windows Communication Foundation (WCF) based service.

IIS 7.0 Pillars

Apart from the change in the core components Microsoft made various changes in five major focus areas. These five areas (see Figure 2) form the pillars of IIS 7.0.

Pasted from <http://www.devx.com/enterprise/Article/34619?trk=DXRSS_LATEST>

Five Major Focus Areas

Security: Security is a subject that any large enterprise must consider before making the decision to adopt a particular web server. IIS 7.0 continues the security initiatives incorporated in IIS 6.0, taking them a step forward by offering a much more modular design. The new modular design splits the features/functionality offered by IIS into multiple fine-grained services that need not be installed when a specific is not required. Figure 3 below illustrates the installation options available for adding or removing a service. IIS 7 ships with more than 40 modules or services that can be added to or removed from an installation as required.

Pasted from <http://www.devx.com/enterprise/Article/34619/0/page/2>

The main advantage of the new modular design is that it helps reduce the footprint of IIS. A reduced footprint maps directly to a reduced surface area for attacks, thus making the web server more secure.

Extensibility: IIS 7.0 has a new set of public APIs that developers can use to extend IIS. Integration with ASP.NET and managed code now lets developers write modules in managed .NET code. Further, IIS sports a unified pipeline, which means that the managed modules do not need to be mapped to the ASP.NET ISAPI to participate in request processing. This means that developers now have a choice of either writing modules using managed code or using the native API to build ISAPI modules. Because IIS is highly modular it is also possible to replace any of the built-in modules with custom built modules if necessary.

Configuration: IIS configuration management has been integrated with the configuration for ASP.NET. This means that IIS also uses a web.config file for storing configuration information, and that you can deploy a specific web server configuration by simply copying the correct web.config file. In IIS 7.0, the metabase has been completely replaced with the web.config file; IIS 7.0 no longer uses the metabase repository used by earlier IIS versions for storing configuration settings.

System Management: IIS 7.0 moves away from the traditional MMC snap-in used by earlier versions and provides a new, more intuitive administrative user interface (see Figure 4) that also integrates and manages ASP.NET configuration information.

You can group the different configurable items based on categories (such as "Application Development" and "Health and Diagnostics") or group them based on Area (such as ASP.NET and IIS). Figure 5 shows the IIS Manager while setting ASP.NET Session configuration.

Diagnostics: IIS 7.0 includes a Failed Request Tracing feature that enables web administrators to capture information related to requests that failed. You can configure failed request processing by setting up rules that set criteria for filtering and logging failed requests. The trace criteria can be configured to monitor only ASP.NET content, or only ASP content or all content as required. You can use status codes to further filter the requests and log the information. IIS 7 provides a wizard-driven interface for defining the rules. Figure 6 shows the wizard interface where you configure the status codes, while Figure 7 shows the log file after a failed request as viewed in an Internet Explorer web browser.

Pasted from <http://www.devx.com/enterprise/Article/34619/0/page/2>

Exploring the Runtime State and Control API

Microsoft ships a new managed API called the Runtime State and Control API (RSCA)) that provides access to runtime information from an IIS-based web server. This API provides information about the different IIS worker processes that are currently running. The API not only lets you gather state information from running processes, it also allows you to modify the state of those processes.

Pasted from <http://www.devx.com/enterprise/Article/34619/0/page/3>

To use the Runtime and State and Control API you need to add a reference to the Microsoft.Web.Administration.dll file, which you'll find on your installation drive in the Windows\System32\inetsrv folder. Figure 8 shows the hierarchy of classes in the Microsoft.Web.Administration namespace.

At the top of the hierarchy is the ServerManager class. The ServerManager class can be used to access the three important aspects related to IIS—the WorkerProcess, the Site, and the ApplicationPool. An instance of ServerManager would hold collections of each of these.

The Sites collection shown in Figure 8 represents the web sites in IIS. It is possible to create new sites as well as iterate through web sites using the object model. The code snippet below illustrates how to create a new web site:

   //Create a New Site
   ServerManager objServerManager = new ServerManager();
   objServerManager.Sites.Add("MyNewSite",
      @"C:\inetpub\wwwroot\MyNewSite", 101);
   objServerManager.CommitChanges();

The next snippet demonstrates how to iterate through all the web sites, starting any web site not already running:

   //Iterate through all Sites
   foreach (Site objSite in objServerManager.Sites)
   {
      string strName = objSite.Name;
      string strState = objSite.State.ToString();
      if (objSite.State != ObjectState.Started)
         objSite.Start();
   }          

You use the WorkerProcesses collection to obtain a reference to any worker process running on the server. For example, to iterate through all the worker processes on a server and display the ProcessId and State properties of each worker process, you'd write code like this:

   //Iterate through all Workerprocesses
   ServerManager objServerManager = new ServerManager();
   foreach(WorkerProcess objWorkerProcess in 
      objServerManager.WorkerProcesses)
   {
      string strProcessId = objWorkerProcess.ProcessId.ToString(); 
      string strState = objWorkerProcess.State.ToString();
   }

The WorkerProcess can also be used to examine the requests that have been processed by a web server. The code snippet below demonstrates the usage of the API to view the requests.

   WorkerProcess objWorkerProcess = objServerManager.WorkerProcesses[0];
   RequestCollection objRequests =  objWorkerProcess.GetRequests(0);
   foreach (Request objRequest in objRequests)
   {
       MessageBox.Show(objRequest.Verb);
       MessageBox.Show(objRequest.ClientIPAddr);
       MessageBox.Show(objRequest.Url);     
   }

Finally, you use the ApplicationPools collection to access the application pools on a server. Again, you can iterate through the pools to perform various operations, such as recycling a pool. The code snippet below iterates through the AppplicationPools collection and recycles each application pool.

   foreach (ApplicationPool objApplicationPool in
      objServerManager.ApplicationPools)
   {
      string strPoolName = objApplicationPool.Name;
      string strPoolState = objApplicationPool.State.ToString();
      objApplicationPool.Recycle();
   }

You can download the IIS 7 Managed Module Starter Kit to get a project template and a guide to help you through your first development project.

Performance Improvements

IIS 7.0 sports performance gains due to improvements in HTTP.sys and because of the Longhorn Networking and file system improvements. Because IIS 7.0 and its corresponding server operating system (Windows Longhorn Server) are still in beta, there are no real-world benchmarks available to provide a more in-depth performance comparison or analysis. Nevertheless, the improvements and optimizations made should result in performance gains.

IIS 7.0 and Windows Editions

IIS 7.0 is available on Windows Vista and will of course be available on Windows Server "Longhorn" Operating Systems as well. Because Windows Vista is a client operating system, there are limitations imposed on IIS on that OS, including simultaneous request execution limit as well as other feature limitations. Only Windows Vista Professional (Professional Edition corresponds to Vista Enterprise, Business, and Ultimate Editions) supports all the IIS features found on the Server Edition, and even that version has a limit of no more than seven simultaneous requests.

Pasted from <http://www.devx.com/enterprise/Article/34619/0/page/3>

IIS 7.0 is one of the products that my team is shipping later this year that I'm most excited about.  It is the most significant release of our web-server that we've done since IIS 1.0, and introduces a huge number of improvements for both administrators and developers.

Mike Volodarsky from the IIS team wrote a great article for the March 2007 MSDN Magazine that summarizes some of the key IIS 7.0 improvements.  I highly recommend reading his excellent article here for a quick summary of some of them.

IIS 7.0 is included within the Windows Vista client release, and is now available with the home editions of the operating system (unlike IIS 5.1 which was only available with XP Professional).  IIS 7.0 for server will ship later this year with Windows Longhorn Server, and will add a bunch of additional deployment features - including much richer hosting support, secure FTP support, and built-in web farm deployment support. 

The web farm support in particular is really cool, and will allow you to deploy your web applications on a file-share that contains all of the code, configuration, content, and encryption keys needed to run a server.  You can then add any number of stateless and configuration-less web-servers into a web farm and just point them at the file-server to dynamically load their configuration settings (including bindings, virtual directories, app pool settings, etc) and application content.  This makes it trivial to scale out applications across machines, and avoid having to use replication schemes for configuration and application deployment (just copy over the files on the file-share and all of the machines in the web farm will immediately pick up the changes). 

The upcoming Beta3 release of Windows Longhorn Server will support a go-live license, so you'll be able to take advantage of this soon.  We are already running www.Microsoft.com on IIS 7.0 clusters (so you'll be in good company!).

ASP.NET and IIS 7.0 Integration

In previous versions of IIS, developers had to write ISAPI extensions/filters to extend the server.  In addition to being a royal pain to write, ISAPIs were also limited in how they plugged into the server and in what they allowed developers to customize.  For example, you can't implement URL Rewriting code within an ISAPI Extension (note: ASP.NET is implemented as an ISAPI extension).  And you end up tying up the I/O threads of the web-server if you write long-running code as an ISAPI Filter (which is why we didn't enable managed code to run in the filter execution phase of a request). 

One of the major architectural changes we made to the core IIS processing engine with IIS7 was to enable much, much richer extensibility via a new modular request pipeline architecture.  You can now write code anywhere within the lifetime of any HTTP request by registering an HTTP Extensibility Module with the web-server.  These extensibility modules can be written using either native C++ code or .NET managed code (you can use the existing ASP.NET System.Web.IHttpModule interface to implement this). 

All "built-in" IIS7 functionality (authentication, authorization, static file serving, directory listing support, classic ASP, logging, etc) is now implemented using this public modular pipeline API.  This means you can optionally remove any of these IIS7 "built-in" features and replace/extend them with your own implementation.

ASP.NET on IIS 7.0 has itself been changed from being implemented as an ISAPI to instead plug in directly as modules within the IIS7 pipeline:

Pasted from <http://weblogs.asp.net/scottgu/archive/2007/04/02/iis-7-0.aspx>

Among the many benefits this brings:

1) You can now use ASP.NET Forms Authentication, Membership/Roles, and any other feature for all requests to the server (for example: .htm, .php, and .jsp files)

2) You can now easily re-write the URL of any web request and/or modify the request in interesting ways

3) You can replace or extend any existing IIS feature using VB or C# (for example: you could remove the built-in directory listing module and plug-in your own).

This really brings a tremendous number of extensibility opportunities to .NET developers.

Pasted from <http://weblogs.asp.net/scottgu/archive/2007/04/02/iis-7-0.aspx>

Using configSource to split configuration files

As Nikhil Kothari writes in his blog, he's started to use the configSource attribute to split configuration files into smaller pieces.

For example, here is how he exports the profile configuration into a dedicated configuration file.
This is web.config:

...
  <system.web>
    ...
    <profile configSource="profile.config" />
    ...
  </system.web>
...

This is profile.config:

<profile>
  <properties>
    <add name="Name" type="String" />
    <add name="Age" type="Int32" />
  </properties>
</profile>
 

Make sure you use .config as the extension of your files so they cannot be served to the browser. Avoid .xml for example or your files can be available to prying eyes.

I've been using this feature for my web sites for a while. This allows having a unique web.config file, and separate sub-files for things that are different between the development machine and the hosting environment. For example, I have different connectionStrings.config and smtp.config files for the two environments. The benefits: the web.config file is smaller and hence easier to read, and you don't need a complete web.config file for each environment.

Testing Private Methods with JUnit and SuiteRunner

Inserted from <http://www.artima.com/suiterunner/privateP.html>

Approaches given in this article are:

Approach 1: Don't Test Private Methods

As I mentioned in the introduction, I first heard the advice to suppress my occasional urges to test private methods from Daniel Steinberg. But Daniel is not only source of this advice that I have encountered. It seems to be a common attitude in the Java community. For example, the JUnit FAQ [4] states:

Testing private methods may be an indication that those methods should be moved into another class to promote reusability.

Charles Miller expressed a similar point of view in his weblog [5]:

If you have a thorough suite of tests for a class's exposed (non-private) interface, those tests should, by their nature, verify that any private method within the class also works. If this isn't the case, or if you have a private method so complex that it needs to be tested out of the context of its public callers, I would consider that a code-smell.

And Dave Thomas and Andy Hunt, in their book Pragmatic Unit Testing [6], write:

In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out.

I believe all this advice. Most of the time, private methods can be most effectively tested via approach 1, indirectly by testing the package-level, protected, and public methods that call them. But inevitably, some people in some situations will feel that directly testing a private method is the right thing to do.

In my case, I tend to create many private utility methods. These utility methods often do nothing with instance data, they just operate on the passed parameters and return a result. I create such methods to make the calling method easier to understand. It is a way to manage the complexity of the implementation of the class. Now, if I extract the private method out of a method that already works and has good unit test coverage, then those existing unit tests will likely suffice. I needn't write more unit tests just for the private method. But if I want to write the private method before its calling method, and I want to write the unit tests before writing the private method, I'm back to wanting to directly test the private method. In the case of private utility methods, I don't feel my urge to directly test the methods is, as the JUnit FAQ put it, "an indication that those methods should be moved into another class to promote reusability." These methods are really only needed in the class in which they reside, and in fact are often only called by one other method.

Another reason I sometimes feel the urge to test private methods directly is that I tend to think of unit testing as helping me achieve a robust system by building that system out of robust parts. Each part is a "unit" for which I can write "unit tests." The unit tests help me ensure each unit is functioning correctly, which in turn helps me build a system that functions correctly as a whole. The primary unit I think in terms of when programming in Java is the class. I build systems out of classes, and unit tests give me confidence that my classes are robust. But to some extent I also feel the same way about the private methods out of which I compose package-access, protected, and public methods. These private methods are units that can be tested individually. Such unit tests give me confidence that the private methods are working correctly, which helps me build package-access, protected, and public methods that are robust.

Approach 2: Give the Methods Package Access

As I mentioned in the introduction, giving methods package access was my first approach to testing private methods with JUnit. This approach actually works just fine, but it does come with a slight cost. When I see a private access specifier on a method, it tells me something I like to know—that this is part of the implementation of the class. I know I can ignore the method if I am just trying to use the class from another class in the package. I could figure this out about a package-access method by looking more closely at the name, documentation, and code of the method, but the word private communicates this far more efficiently. Moreover, the main problem I have with this approach is philosophical. Although I don't mind "breaking encapsulation for the sake of testing," as Dave and Andy would put it, I just don't feel good about breaking encapsulation in a way that changes the package-level API. In other words, although I am quite enthusiastic to test non-public methods of classes, i.e., to create "white-box" unit tests, I'd rather the API of the classes under test, including the package-level API, not be changed to facilitate those tests.

Approach 3: Use a Nested Test Class

A third approach to testing private methods is to nest a static test class inside the production class being tested. Given that a nested class has access to the private members of its enclosing class, it would be able to invoke the private methods directly. The static class itself could be package access, allowing it to be loaded as part of the white box test.

The downside to this approach is that if you don't want the nested test class being accessible in your deployment JAR file, you have to do a bit of extra work to extract it. Also, some people may not like having test code mixed in the same file as production code, though others may prefer that approach.

Approach 4: Use Reflection

The fourth approach to testing private methods was suggested to me by Vladimir R. Bossicard, who wrote JUnit Addons [7]. One day over lunch, Vladimir enlightened me that the java.lang.reflect API included methods that allowed client code to circumvent access protection mechanism of the Java virtual machine. He also told me that his JUnit Addons project included a class, junitx.util.PrivateAccessor [8], to assist in using the reflection API for just this purpose: to write unit tests that manipulate private members of the classes under test. The JUnit FAQ points to a similar class, called PrivilegedAccessor [9], written by Charlie Hubbard and Prashant Dhotke.

One advantage of using the reflection approach to testing private methods is that it provides a clean separation of test code and production code. The tests need not be nested inside the class under test, as in approach 3. Rather, they can be placed alongside the other tests that exercise the package-level and public methods of the class. In addition, you need not alter the API of the class under test. Unlike approach 2, private methods can remain private. Unlike approach 3, you need not add any extra nested class at package access level. The main disadvantage of this approach is that the test code is far more verbose because it uses the reflection API. In addition, refactoring IDEs such as Eclipse and IntelliJ usually aren't as adept at changing the names of methods where they are referred to as Strings passed to the methods of the reflection API. So if you change the name of the private method with your refactoring IDE, you may still have to make some changes by hand in the test code.

Testing private methods (Bruce Eckel's blog)

Pasted from <http://onthethought.blogspot.com/2004/11/testing-private-methods.html>

Testing private methods (TestDriven JUnit Forums discussion)

Pasted from <http://www.testdriven.com/modules/newbb/viewtopic.php?viewmode=thread&order=ASC&topic_id=427&forum=7>

Introduction

Test Driven Development is the practice of (1) writing tests, (2) writing code that passes those tests, and (3) then refactoring. This concept is becoming very popular in the .NET community due to the quality assurance that it adds. While it is easy to test public methods, the natural question emerges "How do I test protected and private methods?"

This article will:

• Summarize some key points of the "Should-you-even-test private methods debate"?
• Make the case that it is still useful to at least know how to test private and protected methods - regardless of which side of the debate you're on.
• Provide the theory and downloadable code sample to demonstrate these testing techniques.

Background Theory

Should You Test Private Methods?

A Google search will show you that there's a lot of debate about using private methods, let alone testing them. The table below summarizes some of the common views of the pro and con for both issues.

There are bright and experienced people on both sides of the issue. So while I have no intention or expectation of ending the "should I test private method" debate, there is still value for both sides to know how to test them. Even if you think that private methods should not be tested:

• Your opinion will be more influential if you can at least show that you are able to test them, but choose not to (i.e. you're not saying "Don't test private methods" simply because you don't know how).
• Having the option of testing non-public methods lets you see what really works best for your team over time.
• As long as there are still some valid situations, it's worth having a convenient way to test them.

Good Criteria and Inadequate Techniques

Andrew Hunt and David Thomas explain in their book, Pragmatic Unit Testing in C# with NUnit, that good unit tests are ATRIP:

• Automatic
• Thorough
• Repeatable
• Independent
• Professional

There are three additional criteria that any testing overhead for private/protected methods should meet:

• Transparency - Don't alter the System Under Test (SUT), such as adding wrapper methods in the production code.
• Scope - Be able to run in both Debug and Release mode.
• Simplicity - Have minimal overhead, and hence be easy to change and simple enough to introduce minimal risk.

Keeping these criteria in mind, there are several strategies that fall short:

Testing Protected Methods

A protected method is visible only to derived classes, therefore it is not immediately available to a test suite. For example, suppose we wanted to test the method from ClassLibrary1.MyObject:

protected string MyProtectedMethod(string strInput, int i32Value) 
{
    return this.Name + ": " + strInput + ", " + 
     i32Value.ToString();
}

The book Pragmatic Unit Testing in C# with NUnit explains one solution: make a derived class MyObjectTester that inherits class MyObject, and then create a public method TestMyProtectedMethod that wraps the protected one. For example:

public new string TestMyProtectedMethod(string strInput, int i32Value) 
{
    return base.MyProtectedMethod(strInput, 
     i32Value);
}

This approach is simple, yet meets all the criteria:

Testing Private Methods

Testing private methods is a little more involved; but we can still do it using System.Reflection. You can use Reflection to dynamically access methods of a type, including both instance and static private methods. Note that accessing private methods does require the ReflectionPermission, but that is not a problem for Unit Tests running on a development machine or build server.

Suppose we wanted to test the private method MyPrivateMethod from ClassLibrary1.MyObject:

private string MyPrivateMethod(string strInput, DateTime dt, double 
 dbl) 
{
    return this.Name + ": " + strInput + ", " + 
     dt.ToString() + ", " + dbl.ToString();
}

One solution is to create a UnitTestUtilities project with a helper class to call the test method via reflection. For example, the download solution has the following methods in UnitTestUtilities.Helper:

public static object RunStaticMethod(System.Type t, string strMethod, 
 object [] aobjParams) 
{
    BindingFlags eFlags = 
     BindingFlags.Static | BindingFlags.Public | 
     BindingFlags.NonPublic;
    return RunMethod(t, strMethod, 
     null, aobjParams, eFlags);
} //end of method

public static object RunInstanceMethod(System.Type t, string strMethod, 
 object objInstance, object [] aobjParams) 
{
    BindingFlags eFlags = BindingFlags.Instance | BindingFlags.Public | 
     BindingFlags.NonPublic;
    return RunMethod(t, strMethod, 
     objInstance, aobjParams, eFlags);
} //end of method

private static object RunMethod(System.Type t, string 
 strMethod, object objInstance, object [] aobjParams, BindingFlags eFlags) 
{
    MethodInfo m;
    try 
    {
        m = t.GetMethod(strMethod, eFlags);
        if (m == null)
        {
             throw new ArgumentException("There is no method '" + 
              strMethod + "' for type '" + t.ToString() + "'.");
        }
                                
        object objRet = m.Invoke(objInstance, aobjParams);
        return objRet;
    }
    catch
    {
        throw;
    }
} //end of method

Private method RunMethod takes in the necessary parameters that Reflection needs to invoke a method, and then returns the value. It has two public methods that wrap this: RunStaticMethod and RunInstanceMethod for static and instance methods respectively.

Walking through RunMethod, it first gets the MethodInfo from a type. Because we expect this to only be called for existing methods, a null method triggers an Exception. Once we have the MethodInfo, we can invoke the method given the instantiated object (null for static methods) and the parameter array.

We could use this Utility in an NUnit test like so:

[Test] public void TestPrivateInstanceMethod()
{
    string strExpected = "MyName: Hello, 5/24/2004 
     12:00:00 AM, 2.1";
     
    ClassLibrary1.MyObject objInstance 
     = new MyObject("MyName");
    
    object obj = 
     UnitTestUtilities.Helper.RunInstanceMethod(
     typeof(ClassLibrary1.MyObject), "MyPrivateMethod",
     objInstance, new object[3] {"Hello", 
     new DateTime(2004,05,24), 2.1});
    
    string strActual = Convert.ToString(obj);
    
    Assert.AreEqual(strExpected,strActual);
}

Conclusion

While there is a debate on whether or not to test private methods, at least we have the ability to do so. We can test protected methods using inheritance to create a derived TesterClass that wraps the base protected methods with public ones. We can test private methods using Reflection, which can be abstracted to a UnitTestUtility helper class. Both of these techniques can help to improve test coverage.

Unit Test Patterns for .NET - Part I

Summary
This article looks at the patterns that are found in Unit Testing. It describes the main patterns found in tested .NET code. It also describes the problems with each pattern. We will be using nUnit for our examples. For more information see nUnit ,Test-Driven Development in .NET and Unit Tests Patterns.

TypeMock
December 10, 2004

• Introduction
• Patterns, Patterns, Patterns
• 4 Stage Testing Pattern
• Test Exception Pattern
• Inner Class Test Pattern
• Reflection Test Pattern
• Mock Object Pattern
• Summary

Introduction

Programmers who have incorporated unit testing into their development process know the advantages it brings: cleaner code, courage to refactor, and higher velocity. Writing tests is easy, it is writing good tests that makes automated unit testing a powerful tool. The following article will give some basic testing patterns that help write good tests, although some cases might need special attention. But first we must understand what a good test is. Following is a list of features that a good test must fulfill:

• Isolation:
  Tests should test only the code that we are going to test. We should not test underlying classes, these should be checked independently. Not testing isolated code will lead to a high coupling between the tests and changing a class might result is many unrelated tests to fail. The normal scope is a class, although sometimes it makes more sense to test a cluster of classes that are closely coupled (functionality wise).
• Speed:
  If running the tests takes too long then developers will be reluctant to run them, as thus we must keep our tests as fast as possible.
• Self containment:
  Tests that rely on external information are prone to fail, and require configurations and setups. This will lead to discarding the test. To make sure that this doesn't happen all the information required for the tests should be in the tests. For example instead of relying on an environment variable to be set, we set it ourselves in the test.
• Race safe:
  Tests must allow being run by multiple users at the safe time. Tests that produce race conditions are prone to make false alarms. If all tests use the same database user, then running the tests by different developers at the same time can lead to false errors.
• Independence:
  Tests should not rely on other tests to be run before or after. But must be able to be run alone, so that developer can run a single test.
• Well Documented:
  Good documentation about what the test is doing will help in understanding the production code. On top of this many developers don't like to read documentation and prefer to see an example of how to use the code. This is fine, and the Tests can be a reference point to this.
• Maintainable:
  Tests should be seen as part of the software code even though it doesn't make it to production. As so it must be maintainable and refactored when needed.

Patterns, Patterns, Patterns

Throughout this article we will use an example of an Authentication class, as it name suggests, this class is responsible for authentication in our system.
Each pattern descripton is devided to three parts:

• When to use the patterns - What are the cases in which we will use the pattern
• How to use the pattern - What are to advices step of the pattern
• Example - Example code in C#

We will now delve into the patterns.

4 Stage Testing Pattern

When to use

This is the normal testing scheme:

How to use

1. Setup prerequisite Objects - Create the scenario of the test, this can be done in the test method or in the [SetUp] and [TestFixtureSetUp] methods
2. Call the method being tested
3. Valuate the results
4. Teardown the Objects

Example

We want to test the EncodePassword method

public class Authentication
{
    private string _key;
    public string Key
    { 
       get  {return _key;} 
       set {_key = value;}
    }
    public string EncodePassword(string password) 
    {
       // do the encoding
       return encoded_password;
    }
}

Here is our test

[TestFixture]
public class TestFixture1
{ 
      Authentication authenticator;
      String name;
      [SetUp] public void Init() 
      {
            // set up our authenticator and key
            authenticator = new Authentication();
            authenticator.Key = "TESTKEY";
            name = "user";
      }
      [TearDown] public void End() 
      {
            // finish tests
            authenticator.Key = "";
      }
      [Test] public void Encoding ()
      {
            // continue specific test set up 
            String expectedKey = "fwe94t-gft5";
            // Call our method
            String recivedKey = authenticator.EncodePassword(name);
            // Validate that for "user" and "TESTKEY" key we should get our key
            Assert.AreEqual(expectedKey,recivedKey);
      }
}

Test Exception Pattern

When to use

When we are expect our test to raise an exception

How to use

Use nUnit's [ExpectedException] attribute

Example

Our  EncodePassword method now throws an exception if the password is empty

public string EncodePassword(string password) 
{
   if (password==null || password.Length==0)
   {
      throw new ValidationException("Password is empty");
   }
   // do the encoding
   return encoded_password;
}

The following code snippet shows a example of how to test exceptions

[Test]
[ExpectedException(ValidationException,"Password is empty")]
public void Encoding ()
{
    authenticator.EncodePassword(null);
}

We expect our test to throw ValidationException with the "Password is empty" error message.

Inner Class Test Pattern

When to use

When a protected entity (field or method), needs to be accessed for the test.
This can be in two situations

1. We need to test a protected method or access a protected field.
2. We need to override a public or protected method.(This can be done only if the method is virtual)

How to use

Create a new class that extends our tested class
To test a protected method, add a method in our extended class that calls the protected method (Delegation).
To override a method, override this method in our extended class.

Example - Test a protected method

The following code snippet shows a example of how to test the protected EncodePassword method.

class TestAuthentication : Authentication
{
      public string CallEncodePassword(string password)
      {
            // We can call a protected method from here
            return EncodePassword(password);
      }
}
[Test] public void Encoding ()
{
      TestAuthentication authenticator = new TestAuthentication();
      authenticator.Key =  "TESTKEY";
      String expectedKey = "fwe94t@#$5";
      String name = "user";
      // call the tested method by means of the Inner Class      
      Assert.AreEqual(expectedKey,authenticator.CallEncodePassword(name));
}

Example - Override a protected method

Lets go back to our example, suppose that the Authentication has the following methods. (The method DoSelect returns the amount of lines that the select returned)

public bool IsAuthenticated(string name,string password)
{
    // do something
    int Results = DoSelect(statement);
    return Results==1;
}
protected virtual int DoSelect(string statement)
{
      // do something
}

We want to check that the IsAuthenticated is acting correctly but without setting up a database of passwords. We can override the DoSelect method and return our own values. We can then test if DoSelect works using the Inner Class Test Pattern for testing a protected method.

[Test] public void Authenticated ()
{
      TestAuthentication authenticator = new TestAuthentication();

      // if 1 record found should be authenticated
      authenticator.returnAmount = 1;
      Assert.IsTrue(authenticator.IsAuthenticated("user","password"));        

      // if no records found should not be authenticated
      authenticator.returnAmount = 0;
      Assert.IsFalse(authenticator.IsAuthenticated("user","password"));
}

Reflection Test Pattern

When to use

When we need to test private methods use the reflection test pattern.

In most cases we don't need to test private methods. It is enough to test the public ones, although there are some cases where this is needed. For example: If we have a Perfect Binary Tree class with get and put methods, we can check that the tree works, but we still need to test that the tree is perfect, this can be done only if we test the private method that resorts the tree.

How to use

Use reflection.

Example

[Test]
public void Internals ()
{
      Type type = typeof (Authentication);
      Authentication authenticator = (Authentication)type.GetConstructor
        (System.Type.EmptyTypes).Invoke(null);
      bool field = (bool)type.GetField("privateField").GetValue(authenticator);
      Assert.IsTrue(field);
      bool result = (bool)type.GetMethod("PrivateMethod").Invoke(instance,null);
      Assert.IsTrue(result);
}

Mock Object Pattern

Mock objects are objects that replace the real objects and return hard coded values. This helps in testing the class in isolation.

There is a difference between Mocks and Stubs. A stub is used to simulate an object. Stubs are typically used to stub out objects that are expensive to create or manipulate, whereas Mocks are used to test Interactions between classes. This is a big difference. There's a good article by Martin Fowler about mocks and stubs: http://martinfowler.com/articles/mocksArentStubs.html.

As said, Mocks are used to validate that the interactions between Objects are as expected.

 Do not attempt to reproduce real behavior in a mock object; if they are becoming complex, revisit both the mock implementation and the code being tested to see if there is some intermediate concept to be factored out.

Dynamic Mock Frameworks are frameworks that build Mock Objects on the fly. There are quite a few mock object frameworks. The difference between them is in the way that the developer writes the interactions with the object.

When to use

Mock Objects can be used in the following situations

• The real object has non deterministic behavior (it produces unpredictable results, like a date or the current weather temperature.)
• The real object is difficult to set up.
• The real object has behavior that is hard to trigger (for example, a network error).
• The real object is slow.
• The real object has (or is) a user interface.
• The test needs to ask the real object about how it was used (for example, a test might need to confirm that a callback function was actually called).
• The real object does not yet exist (a common problem when interfacing with other teams or new hardware systems).

How to use

 The three key steps to using mock objects for testing are:

1. Use an Interface to describe the object
2. Implement the interface for production code
3. Implement the interface in a mock object for testing

Example - using nUnit.Mock framework

Suppose our code implements a call back each time an Authentication is called

IList subscriber;
public void AddSubscriber(ISubscriber subscriber)
{
      this.subscriber.Add(subscriber);
}
public bool IsAuthenticated(string name,string password)
{
    foreach (ISubscriber sub in subscriber)
    {
        sub.Recive(name);
    }
    // do something
    int Results = DoSelect(statment);
    return Results==1;
}

public interface ISubscriber 
{
    void Receive(String message);
}    

Here is a test

[Test]
public void Subscriber()
{
   1 DynamicMock subscriber = new DynamicMock(typeof(ISubscriber));
     Authentication authenticator = new Authentication();
   2 authenticator.Add((ISubscriber) subscriber.MockInstance);
     // expectations
   3 subscriber.Expect("Receive",new Object[] {"user"});
     // execute
     Assert.IsTrue(authenticator.IsAuthenticated("user","password"));        
   4 subscriber.Verify();
}

 There are mock frameworks that implement mock objects for common types, (System.Data for example).

Summary

In this article, we have introduced the common unit test patterns. These patterns can be use by themselves or in combinations (For example you want to mock a database connection, but this connection is created in a protected virtual method, The test will use the Inner Class Pattern to return the Mock database object and with a mock object for the actual database.

There are still many situations where these patterns are not sufficient and there is a need to change code to make it testable. These include:

• Singleton classes
• Calls to static members
• Objects that do not have an Interface (as required for Mock Object Pattern)
• Objects that are instantiated in the code being tested
• Objects that are not passes to the method (as required for Mock Object Pattern).
  

These will be covered in part II - Type Mock Pattern

http://peeyes.spaces.live.com/blog/cns!9D867CC7936D3E20!539.entry

Martin Fowler

Contents

• Regular Tests
• Tests with Mock Objects
  • Using EasyMock
• The Difference Between Mocks and Stubs
• Classical and Mockist Testing
• Choosing Between the Differences
  • Driving TDD
  • Fixture Setup
  • Test Isolation
  • Coupling Tests to Implementations
  • Design Style
• So should I be a classicist or a mockist?
• Final Thoughts

I first came across the term "mock object" a few years ago in the XP community. Since then I've run into mock objects more and more. Partly this is because many of the leading developers of mock objects have been colleagues of mine at ThoughtWorks at various times. Partly it's because I see them more and more in the XP-influenced testing literature.

But as often as not I see mock objects described poorly. In particular I see them often confused with stubs - a common helper to testing environments. I understand this confusion - I saw them as similar for a while too, but conversations with the mock developers have steadily allowed a little mock understanding to penetrate my tortoiseshell cranium.

This difference is actually two separate differences. On the one hand there is a difference in how test results are verified: a distinction between state verification and behavior verification. On the other hand is a whole different philosophy to the way testing and design play together, which I term here as the classical and mockist styles of Test Driven Development.

(In the earlier version of this essay I had realized there was a difference, but combined the two differences together. Since then my understanding has improved, and as a result it's time to update this essay. If you haven't read the previous essay you can ignore my growing pains, I've written this essay as if the old version doesn't exist. But if you are familiar with the old version you may find it helpful to note that I've broken the old dichotomy of state based testing and interaction based testing into the state/behavior verification dichotomy and the classical/mockist TDD dichotomy. I've also adjusted my vocabulary to match that of the Gerard Meszaros's upcoming xUnit patterns book.)

Regular Tests

I'll begin by illustrating the two styles with a simple example. (The example is in Java, but the principles make sense with any object-oriented language.) We want to take an order object and fill it from a warehouse object. The order is very simple, with only one product and a quantity. The warehouse holds inventories of different products. When we ask an order to fill itself from a warehouse there are two possible responses. If there's enough product in the warehouse to fill the order, the order becomes filled and the warehouse's amount of the product is reduced by the appropriate amount. If there isn't enough product in the warehouse then the order isn't filled and nothing happens in the warehouse.

These two behaviors imply a couple of tests, these look like pretty conventional JUnit tests.

public class OrderStateTester extends TestCase {
  private static String TALISKER = "Talisker";
  private static String HIGHLAND_PARK = "Highland Park";
  private Warehouse warehouse = new WarehouseImpl();

  protected void setUp() throws Exception {
    warehouse.add(TALISKER, 50);
    warehouse.add(HIGHLAND_PARK, 25);
  }
  public void testOrderIsFilledIfEnoughInWarehouse() {
    Order order = new Order(TALISKER, 50);
    order.fill(warehouse);
    assertTrue(order.isFilled());
    assertEquals(0, warehouse.getInventory(TALISKER));
  }
  public void testOrderDoesNotRemoveIfNotEnough() {
    Order order = new Order(TALISKER, 51);
    order.fill(warehouse);
    assertFalse(order.isFilled());
    assertEquals(50, warehouse.getInventory(TALISKER));
  }

xUnit tests follow a typical four phase sequence: setup, exercise, verify, teardown. In this case the setup phase is done partly in the setUp method (setting up the warehouse) and partly in the test method (setting up the order). The call to order.fill is the exercise phase. This is where the object is prodded to do the thing that we want to test. The assert statements are then the verification stage, checking to see if the exercised method carried out its task correctly. In this case there's no explicit teardown phase, the garbage collector does this for us implicitly.

During setup there are two kinds of object that we are putting together. Order is the class that we are testing, but for Order.fill to work we also need an instance of Warehouse. In this situation Order is the object that we are focused on testing. Testing-oriented people like to use terms like object-under-test or system-under-test to name such a thing. Either term is an ugly mouthful to say, but as it's a widely accepted term I'll hold my nose and use it. Following Meszaros I'll use System Under Test, or rather the abbreviation SUT.

So for this test I need the SUT (Order) and one collaborator (warehouse). I need the warehouse for two reasons: one is to get the tested behavior to work at all (since Order.fill calls warehouse's methods) and secondly I need it for verification (since one of the results of Order.fill is a potential change to the state of the warehouse). As we explore this topic further you'll see there we'll make a lot of the distinction between SUT and collaborators. (In the earlier version of this article I referred to the SUT as the primary object and collaborators and secondary objects)

This style of testing uses state verification: which means that we determine whether the exercised method worked correctly by examining the state of the SUT and its collaborators after the method was exercised. As we'll see, mock objects enable a different approach to verification.

Tests with Mock Objects

Now I'll take the same behavior and use mock objects. For this code I'm using the jMock library for defining mocks. jMock is a java mock object library. There are other mock object libraries out there, but this one is an up to date library written by the originators of the technique, so it makes a good one to start with.

public class OrderInteractionTester extends MockObjectTestCase {
  private static String TALISKER = "Talisker";

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    Mock warehouseMock = new Mock(Warehouse.class);
    
    //setup - expectations
    warehouseMock.expects(once()).method("hasInventory")
      .with(eq(TALISKER),eq(50))
      .will(returnValue(true));
    warehouseMock.expects(once()).method("remove")
      .with(eq(TALISKER), eq(50))
      .after("hasInventory");

    //exercise
    order.fill((Warehouse) warehouseMock.proxy());
    
    //verify
    warehouseMock.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    
    Mock warehouse = mock(Warehouse.class);
      
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());

    assertFalse(order.isFilled());
  }

Concentrate on testFillingRemovesInventoryIfInStock first, as I've taken a couple of shortcuts with the later test.

To begin with, the setup phase is very different. For a start it's divided into two parts: data and expectations. The data part sets up the objects we are interested in working with, in that sense it's similar to the traditional setup. The difference is in the objects that are created. The SUT is the same - an order. However the collaborator isn't a warehouse object, instead it's a mock warehouse - technically an instance of the class Mock.

The second part of the setup creates expectations on the mock object.The expectations indicate which methods should be called on the mocks when the SUT is exercised.

Once all the expectations are in place I exercise the SUT. After the exercise I then do verification, which has two aspects. I run asserts against the SUT - much as before. However I also verify the mocks - checking that they were called according to their expectations.

The key difference here is how we verify that the order did the right thing in its interaction with the warehouse. With state verification we do this by asserts against the warehouse's state. Mocks use behavior verification, where we instead check to see if the order made the correct calls on the warehouse. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification. Only the order is checked using asserts, and if the the method doesn't change the state of the order there's no asserts at all.

In the second test I do a couple of different things. Firstly I create the mock differently, using using the mock method in MockObjectTestCase rather than the constructor. This is a convenience method in the jMock library that means that I don't need to explicitly call verify later on, any mock created with the convenience method is automatically verified at the end of the test. I could have done this is the first test too, but I wanted to show the verification more explicitly to show how testing with mocks works.

The second different thing in the second test case is that I've relaxed the constraints on the expectation by using withAnyArguments. The reason for this is that the first test checks that the number is passed to the warehouse, so the second test need not repeat that element of the test. If the logic of the order needs to be changed later, then only one test will fail, easing the effort of migrating the tests. As it turns out I could have left withAnyArguments out entirely, as that is the default.

Using EasyMock

There are a number of mock object libraries out there. One that I come across a fair bit is EasyMock, both in its java and .NET versions. EasyMock also enable behavior verification, but has a couple of differences in style with jMock which are worth discussing. Here are the familiar tests again:

public class OrderEasyTester extends TestCase {
  private static String TALISKER = "Talisker";
  
  private MockControl warehouseControl;
  private Warehouse warehouseMock;
  
  public void setUp() {
    warehouseControl = MockControl.createControl(Warehouse.class);
    warehouseMock = (Warehouse) warehouseControl.getMock();    
  }

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    
    //setup - expectations
    warehouseMock.hasInventory(TALISKER, 50);
    warehouseControl.setReturnValue(true);
    warehouseMock.remove(TALISKER, 50);
    warehouseControl.replay();

    //exercise
    order.fill(warehouseMock);
    
    //verify
    warehouseControl.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    

    warehouseMock.hasInventory(TALISKER, 51);
    warehouseControl.setReturnValue(false);
    warehouseControl.replay();

    order.fill((Warehouse) warehouseMock);

    assertFalse(order.isFilled());
    warehouseControl.verify();
  }
}

EasyMock uses a record/replay metaphor for setting expectations. For each object you wish to mock you create a control and mock object. The mock satisfies the interface of the secondary object, the control gives you additional features. To indicate an expectation you call the method, with the arguments you expect on the mock. You follow this with a call to the control if you want a return value. Once you've finished setting expectations you call replay on the control - at which point the mock finishes the recording and is ready to respond to the primary object. Once done you call verify on the control.

It seems that while people are often fazed at first sight by the record/replay metaphor, they quickly get used to it. It has an advantage over the constraints of jMock in that you are making actual method calls to the mock rather than specifying method names in strings. This means you get to use code-completion in your IDE and any refactoring of method names will automatically update the tests. The downside is that you can't have the looser constraints.

The developers of jMock are working on a new version which will use other techniques to allow you use actual method calls.

The Difference Between Mocks and Stubs

When they were first introduced, many people easily confused mock objects with the common testing notion of using stubs. Since then it seems people have better understood the differences (and I hope the earlier version of this paper helped). However to fully understand the way people use mocks it is important to understand mocks and other kinds of test doubles. ("doubles"? Don't worry if this is a new term to you, wait a few paragraphs and all will be clear.)

When you're doing testing like this, you're focusing on one element of the software at a time - hence the common term unit testing. The problem is that to make a single unit work, you often need other units - hence the need for some kind of warehouse in our example.

In the two styles of testing I've shown above, the first case uses a real warehouse object and the second case uses a mock warehouse, which of course isn't a real warehouse object. Using mocks is one way to not use a real warehouse in the test, but there are other forms on unreal objects used in testing like this.

The vocabulary for talking about this soon gets messy - all sorts of words are used: stub, mock, fake, dummy. For this article I'm going to follow the vocabulary of Gerard Meszaros's upcoming book. It's not what everyone uses, but I think it's a good vocabulary and since it's my essay I get to pick which words to use.

Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined four particular kinds of double:

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
• Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Of these kinds of doubles, only mocks insist upon behavior verification. The other doubles can, and usually do, use state verification. Mocks actually do behave like other doubles during the exercise phase, as they need to make the SUT believe it's talking with its real collaborators - but mocks differ in the setup and the verification phases.

To explore test doubles a bit more, we need to extend our example. Many people only use a test double if the real object is awkward to work with. A more common case for a test double would be if we said that we wanted to send an email message if we failed to fill an order. The problem is that we don't want to send actual email messages out to customers during testing. So instead we create a test double of our email system, one that we can control and manipulate.

Here we can begin to see the difference between mocks and stubs. If we were writing a test for this mailing behavior, we might write a simple stub like this.

public interface MailService {
  public void send (Message msg);
}

public class MailServiceStub implements MailService {
  private List<Message> messages = new ArrayList<Message>();
  public void send (Message msg) {
    messages.add(msg);
  }
  public int numberSent() {
    return messages.size();
  }
}                                 

We can then use state verification on the stub like this.

class OrderStateTester...
  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();
    order.setMailer(mailer);
    order.fill(warehouse);
    assertEquals(1, mailer.numberSent());
  }

Of course this is a very simple test - only that a message has been sent. We've not tested it was send to the right person, or with the right contents, but it will do to illustrate the point.

Using mocks this test would look quite different.

class OrderInteractionTester...
  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    Mock warehouse = mock(Warehouse.class);
    Mock mailer = mock(MailService.class);
    order.setMailer((MailService) mailer.proxy());

    mailer.expects(once()).method("send");
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());
  }
}

In both cases I'm using a test double instead of the real mail service. There is a a difference in that the stub uses state verification while the mock uses behavior verification.

In order to use state verification on the stub, I need to make some extra methods on the stub to help with verification. As a result the stub implements MailService but adds extra test methods.

Mock objects always use behavior verification, a stub can go either way. Meszaros refers to stubs that use behavior verification as a Test Spy. The difference is in how exactly the double runs and verifies and I'll leave that for you to explore on your own.

Classical and Mockist Testing

Now I'm at the point where I can explore the second dichotomy: that between classical and mockist TDD. The big issue here is when to use a mock (or other double).

The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn't really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior. In this case for both the warehouse and the mail service.

Although the various mock frameworks were designed with mockist testing in mind, many classicists find them useful for creating doubles.

An important offshoot of the mockist style is that of Behavior Driven Development (BDD). BDD was originally developed by my colleague Dan North as a technique to better help people learn Test Driven Development by focusing on how TDD operates as a design technique. This led to renaming tests as behaviors to better explore where TDD helps with thinking about what an object needs to do. BDD takes a mockist approach, but it expands on this, both with its naming styles, and with its desire to integrate analysis within its technique. I won't go into this more here, as the only relevance to this article is that BDD is another variation on TDD that tends to use mockist testing. I'll leave it to you to follow the link for more information.

Choosing Between the Differences

In this article I've explained a pair of differences: state or behavior verification / classic or mockist TDD. What are the arguments to bear in mind when making the choices between them? I'll begin with the state versus behavior verification choice.

The first thing to consider is the context. Are we thinking about a easy collaboration, such as order and warehouse, or an awkward one, such as order and mail service?

If it's an easy collaboration then the choice is simple. If I'm a classic TDDer I don't use a mock, stub or any kind of double. I use a real object and state verification. If I'm a mockist TDDer I use a mock and behavior verification. No decisions at all.

If it's an awkward collaboration, then there's no decision if I'm a mockist - I just use mocks and behavior verification. If I'm a classicist then I do have a choice, but it's not a big deal which one to use. Usually classicists will decide on a case by case basis, using the easiest route for each situation.

So as we see, state versus behavior verification is mostly not a big decision. The real issue is between classic and mockist TDD. As it turns out the characteristics of state and behavior verification do affect that discussion, and that's where I'll focus most of my energy.

But before I do, let me throw in an edge case. Occasionally you do run into things that are really hard to use state verification on, even if they aren't awkward collaborations. A great example of this is a cache. The whole point of a cache is that you can't tell from its state whether the cache hit or missed - this is a case where behavior verification would be the wise choice for even a hard core classical TDDer. I'm sure there are other exceptions in both directions.

As we delve into the classic/mockist choice, there's lots of factors to consider, so I've broken them out into rough groups.

Driving TDD

Mock objects came out of the XP community, and one of the principal features of XP is its emphasis on Test Driven Development - where a system design is evolved through iteration driven by writing tests.

Thus it's no surprise that the mockists particularly talk about the effect of mockist testing on a design. In particular they advocate a style called need-driven development. With this style you begin developing a story by writing your first test for the outside of your system, making some interface object your SUT. By thinking through the expectations upon the collaborators, you explore the interaction between the SUT and its neighbors - effectively designing the outbound interface of the SUT.

Once you have your first test running, the expectations on the mocks provide a specification for the next step and a starting point for the tests. You turn each expectation into a test on a collaborator and repeat the process working your way into the system one SUT at a time. This style is also referred to as outside-in, which is a very descriptive name for it. It works well with layered systems. You first start by programming the UI using mock layers underneath. Then you write tests for the lower layer, gradually stepping through the system one layer at a time. This is a very structured and controlled approach, one that many people believe is helpful to guide newcomers to OO and TDD.

Classic TDD doesn't provide quite the same guidance. You can do a similar stepping approach, using stubbed methods instead of mocks. To do this you whenever you need something from a collaborator you just hard-code exactly the response the test requires to make the SUT work. Then once you're green with that you replace the hard coded response with a the proper code.

But classic TDD can do other things too. A common style is middle-out. In this style you take a feature and decide what you need in the domain for this feature to work. You get the domain objects to do what you need and once they are working you layer the UI on top. Doing this you might never need to fake anything. A lot of people like this because it focuses attention on the domain model first, which helps keep domain logic from leaking into the UI.

I should stress that both mockist and classicists do this one story at a time. There is a school of thought that builds application layer by layer, not starting one layer until another is complete. Both classicists and mockists tend to have an agile background and prefer fine-grained iterations. As a result they work feature by feature rather than layer by layer.

Fixture Setup

With classic TDD, you have to create not just the SUT but also all the collaborators that the SUT needs in response to the test. While the example only had a couple of objects, real tests often involve a large amount of secondary objects. Usually these objects are created and torn down with each run of the tests.

Mockist tests, however, only need to create the SUT and mocks for its immediate neighbors. This can avoid some of the involved work in building up complex fixtures (At least in theory. I've come across tales of pretty complex mock setups, but that may be due to not using the tools well.)

In practice, classic testers tend to reuse complex fixtures as much as possible. In the simplest way you do this by putting fixture setup code into the xUnit setup method. More complicated fixtures need to be used by several test classes, so in this case you create special fixture generated classes. I usually call these Object Mothers, based on a naming convention used on an early ThoughtWorks XP project. Using mothers is essential in larger classic testing, but the mothers are additional code that need to be maintained and any changes to the mothers can have significant ripple effects through the tests. There also may be a performance cost in setting up the fixture - although I haven't heard this to be a serious problem when done properly. Most fixture objects are cheap to create, those that aren't are usually doubled.

As a result I've heard both styles accuse the other of being too much work. Mockists say that creating the fixtures is a lot of effort, but classicists say that this is reused but you have to create mocks with every test.

Test Isolation

If you introduce a bug to a system with mockist testing, it will usually cause only tests whose SUT contains the bug to fail. With the classic approach, however, any tests of client objects can also fail, which leads to failures where the buggy object is used as a collaborator in another object's test. As a result a failure in a highly used object causes a ripple of failing tests all across the system.

Mockist testers consider this to be a major issue; it results in a lot of debugging in order to find the root of the error and fix it. However classicists don't express this as a source of problems. Usually the culprit is relatively easy to spot by looking at which tests fail and the developers can tell that other failures are derived from the root fault. Furthermore if you are testing regularly (as you should) then you know the breakage was caused by what you last edited, so it's not difficult to find the fault.

One factor that may be significant here is the granularity of the tests. Since classic tests exercise multiple real objects, you often find a single test as the primary test for a cluster of objects, rather than just one. If that cluster spans many objects, then it can be much harder to find the real source of a bug. What's happening here is that the tests are too coarse grained.

It's quite likely that mockist tests are less likely to suffer from this problem, because the convention is to mock out all objects beyond the primary, which makes it clear that finer grained tests are needed for collaborators. That said, it's also true that using overly coarse grained tests isn't necessarily a failure of classic testing as a technique, rather a failure to do classic testing properly. A good rule of thumb is to ensure that you separate fine-grained tests for every class. While clusters are sometimes reasonable, they should be limited to only very few objects - no more than half a dozen. In addition, if you find yourself with a debugging problem due to overly coarse-grained tests, you should debug in a test driven way, creating finer grained tests as you go.

In essence classic xunit tests are not just unit tests, but also mini-integration tests. As a result many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact. Mockist tests lose that quality. In addition you also run the risk that expectations on mockist tests can be incorrect, resulting in unit tests that run green but mask inherent errors.

It's at this point that I should stress that whichever style of test you use, you must combine it with coarser grained acceptance tests that operate across the system as a whole. I've often come across projects which were late in using acceptance tests and regretted it.

Coupling Tests to Implementations

When you write an mockist test, you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers. A classic test only cares about the final state - not how that state was derived. Mockist tests are thus more coupled to the implementation of a method. Changing the nature of calls to collaborators usually cause a mockist test to break.

This coupling leads to a couple of concerns. The most important one is the effect on Test Driven Development. With mockist testing, writing the test makes you think about the implementation of the behavior - indeed mockist testers see this as an advantage. Classicists, however, think that it's important to only think about what happens from the external interface and to leave all consideration of implementation until after you're done writing the test.

Coupling to the implementation also interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing.

This can be worsened by the nature of mock toolkits. Often mock tools specify very specific method calls and parameter matches, even when they aren't relevant to this particular test. One of the aims of the jMock toolkit is to be more flexible in its specification of the expectations to allow expectations to be looser in areas where it doesn't matter, at the cost of using strings that can make refactoring more tricky.

Design Style

One of the most fascinating aspects of these testing styles to me is how they affect design decisions. As I've talked with both types of tester I've become aware of a few differences between the designs that the styles encourage, but I'm sure I'm barely scratching the surface.

I've already mentioned a difference in tackling layers. Mockist testing supports an outside-in approach while developers who prefer a domain model out style tend to prefer classic testing.

On a smaller level I noticed that mockist testers tend to ease away from methods that return values, in favor of methods that act upon a collecting object. Take the example of the behavior of gathering information from a group of objects to create a report string. A common way to do this is to have the reporting method call string returning methods on the various objects and assemble the resulting string in a temporary variable. A mockist tester would be more likely to pass a string buffer into the various objects and get them to add the various strings to the buffer - treating the string buffer as a collecting parameter.

Mockist testers do talk more about avoiding 'train wrecks' - method chains of style of getThis().getThat().getTheOther(). Avoiding method chains is also known as following the Law of Demeter. While method chains are a smell, the opposite problem of middle men objects bloated with forwarding methods is also a smell. (I've always felt I'd be more comfortable with the Law of Demeter if it were called the Suggestion of Demeter.)

One of the hardest things for people to understand in OO design is the "Tell Don't Ask" principle, which encourages you to tell an object to do something rather than rip data out of an object to do it in client code. Mockists say that using mockist testing helps promote this and avoid the getter confetti that pervades too much of code these days. Classicists argue that there plenty other ways to do this.

An acknowledged issue with state-based verification is that it can lead to creating query methods only to support verification. It's never comfortable to add methods to the API of an object purely for testing, using behavior verification avoids that problem. The counter-argument to this is that such modification are usually minor in practice.

Mockists favor role interfaces and assert that using this style of testing encourages more role interfaces, since each collaboration is mocked separately and is thus more likely to be turned into a role interface. So in my example above using a string buffer for generating a report, a mockist would be more likely to invent a particular role that makes sense in that domain, which may be implemented by a string buffer.

It's important to remember that this difference in design style is key motivator for most mockists. TDD's origins were a desire to get strong automatic regression testing that supported evolutionary design. Along the way its practitioners discovered that writing tests first made a significant improvement to the design process. Mockists have a strong idea of what kind of design is a good design and have developed mock libraries primarily to help people develop this design style.

So should I be a classicist or a mockist?

I find this a difficult question to answer with confidence. Personally I've always been a old fashioned classic TDDer and thus far I don't see any reason to change. I don't see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation.

This has particularly struck me when I've observed a mockist programmer. I really like the fact that while writing the test you focus on the result of the behavior, not how it's done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations. This feels really unnatural to me.

I also suffer from the disadvantage of not trying mockist TDD on anything more than toys. As I've learned from Test Driven Development itself, it's often hard to judge a technique without trying it seriously. I do know many good developers who are very happy and convinced mockists. So although I'm still a convinced classicist, I'd rather present both arguments as fairly as I can so you can make your own mind up.

So if mockist testing sounds appealing to you, I'd suggest giving it a try. It's particularly worth trying if you are having problems in some of the areas that mockist TDD is intended to improve. I see two main areas here. One is if you're spending a lot of time debugging when tests fail because they aren't breaking cleanly and telling you where the problem is. (You could also improve this by using classic TDD on finer-grained clusters.) The second area is if your objects don't contain enough behavior, mockist testing may encourage the development team to create more behavior rich objects.

Final Thoughts

As interest in unit testing, the xunit frameworks and Test Driven Development has grown; more and more people are running into mock objects. A lot of the time people learn a bit about the mock object frameworks, without fully understanding the mockist/classical divide that underpins them. Whichever side of that divide you lean on, I think it's useful to understand this difference in views. While you don't have to be a mockist to find the mock frameworks handy, it is useful to understand the thinking that guides many of the design decisions of the software.

The purpose of this article was, and is, to point out these differences and to lay out the trade-offs between them. There is more to mockist thinking than I've had time to go into, particularly its consequences on design style. I hope that in the next few years we'll see more written on this and that will deepen our understanding of the fascinating consequences of writing tests before the code.

Any piece of code which doesn’t have tests is ‘Legacy Code’…

These are the key points in the ThoughtWorks session.

First Topic: Refactoring Databases:  (Speaker: Pramod Sagalage)

Practices to follow:

1.      Database design should be in configuration management tool.

2.      Everyone shouldhave a database setup in their own machine.

Make the regular tasks(like creating user ,creating database setup for the new joinee) automated.

There must have deltas and undos in scripts so that we can easily trace the build versions.

As a good developer add comments while checkin

Cruisecontrol description:  Build Results, See Artifacts( can see source code,delta scripts)

Refactoring Databases book contains 67 refactoring techniques.

Some examples:

If datatype for a particular column of a table in the middle of the project then how to minimize the effect in the already developed application

By refactoring ,DB migration will become easy.

Articles to refer:

www.martinfowler.com

www.databaserefactoring.com/pramodsadalage.html

groups.yahoo.com/group/agiledatabase

ambysoft.com/agiledatabasetechniques.html

dbdeploy.com

Second Session: Evolutionary Testing( Vivek Prahlad)

Feedback is the foundation for Agile Methodology.

When selecting automated testing tool things to consider are:

1.Testing and development languages are similar.

2.Tool should insulate against the UI changes.

Then he spoke about Selenium tool.

1.is a  functional testing tool.

2. open source web testing tool.

3. Cross browser,cross platform.

4.Can test Ajax applications

5. can test ruby,java,net applications

Selenium plugin should be added in the coding editor.

Acceptance Test Driven Development:

Start writing the test cases before the developers start coding.

DRY: Don’t Repeat Yourslef

Testing Patterns:

1.Screen Object pattern

2.Data Template Pattern

3.Workflow Pattern

4.Verify vs Asset

Make the test cases refactor.

Third Session: Domain Specific Languages:         Hari

Styles of DSL:

1.External DSL

2.Internal DSL

That’s it I learnt from the third session

Process and request identity in ASP.NET

http://support.microsoft.com/kb/317012

SUMMARY

MORE INFORMATION

<processModel  userName="machine" password="AutoGenerate" />
				

<processModel  userName="SYSTEM" password="AutoGenerate" />
				

<identity impersonate="true"/>
				

http://www.codeproject.com/aspnet/exploresessionandcache.asp

Please find the list of Streamzines for unit testing.

http://www.netobjectives.com/streamzines/TheCaseForUnitTesting/player.html

http://www.netobjectives.com/streamzines/NUnitFundamentals/player.html

http://www.netobjectives.com/streamzines/MockObjectsAndMockTurtles/player.html