Nick Parker
My ramblings on .NET...

Mock Object Discussion

Thursday, 14 September 2006 13:03 by nickp
Scott Hanselman has a great discussion on mock objects on Hanselminutes. They go over the basics of how mocks fit into the development environement and how it helps in a test driven development environment. Scott mentions how the Expect API of many mock object frameworks read like an english sentence, this is a great example of a fluent interface. Scott points out one of the most apparent reasons why Rhino Mocks is a great mock library, it doesn't rely on string-based method names, you actually use the method in your expectations. This is great because it allows developers to lean on the compiler, this can be especially useful as you refactor your code base

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   .NET | Agile | Software | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Bored During Build Time?

Tuesday, 25 July 2006 17:27 by nickp
It's very important to keep your build time as short as possible, but everyone has to deal with it one way or another. If you enjoy anagrams, try waitingforbuild.com next time you are waiting for your build process to complete. On a serious note, if your build time is extremely long (can you eat lunch during your build?) then the next step is to shorten your build time to increase the feedback loop within your development team. The longer your feedback loop is among the development team, the longer it will take to fix bugs when they are identified. A common area where this occurs is where integration tests are used within the smoke test suite. By the nature of integration tests, they tend to take much longer than simple unit tests. Integration tests require outside resources such as a network or database, all which take time to run - assuming they are all available during the run. Remember, if your unit test requires a network resource, file or database connection, it is not truely a unit test. There is nothing wrong with having these types of tests available to be run, however using those within a smoke testing suite can produce inconsistent results that may be misleading. Thoughts?

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   Agile | CI | Software | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Test Driven Development Discussion

Wednesday, 14 June 2006 12:00 by nickp

Last night I had the opportunity to go to dinner with the Visual C# Team, C# MVP's and Regional Directors. I had an interesting discussion with Bill Wagner on the merits of having development teams following the test driven development methodology. It was a hearty discussion where I attempted to play the devil advocate in support of full compliance of the TDD approach.

I also had the chance to chat with Jeffrey Palermo about some of the idiosyncrasies related to the configuration file within StructureMap and the immediate value ReSharper provides to development teams.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   .NET | Software | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Rhino Mocks To The Rescue

Tuesday, 6 June 2006 16:38 by nickp
A recent discussion on the Test Driven Development group brought in question the lacking ability of NMock for mocking classes. NMock will currently only mock an interface. The problem arose when the author wanted to mock a class that takes parameters in its constructor. His solution is to add an Initialize method to the interface and then every other method checks to confirm the object was initialized. While that is very mechanical and error prone - it does work, however there is another solution. Rhino Mocks allows you to create a PartialMock of a class with parameterized constructor arguments (I could even inject a mocked instance as a parameter for my partial mock). Ultimately you don't want your testing infrastructure to dictate too heavily the design of your application. Here is an example where we are able to test the GetId method without creating a derived class to provide the override implementation:

 

public abstract class DomainObject
{
public virtual Guid GetUser()
{
Guid g
= GetId();
if
(g == Guid.Empty)
{
g
= Guid.NewGuid();
}
return g;
}
public abstract Guid GetId();
}

[Test()]
public void PatialMock()
{
MockRepository mocks
= new MockRepository();
DomainObject anObject =
(DomainObject)mocks.PartialMock(typeof(DomainObject));
Guid g = Guid.NewGuid();
Expect.Call(anObject.GetId()).Return(g);
mocks.ReplayAll();
Assert.AreEqual(g, anObject.GetUser());
mocks.VerifyAll();
}

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   Open Source | .NET | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Dependency Injection with StructureMap

Wednesday, 31 May 2006 20:19 by nickp
I have posted previously about using Spring.NET as an IoC container and how we can implement some of this out of the box with the System.ComponentModel namespace. StructureMap is another dependency injection framework that in my opinon is much more approachable than Spring out of the box. Why? - Let's take a look at what it takes to start requesting services from the StructureMap container.

 

IRule rule = ObjectFactory.GetInstance<IRule>();
or for .NET 1.1

 

IRule rule = ObjectFactory.GetInstance(typeof(IRule)) as IRule;
To begin with, StructureMap now supports generics (granted the 1.0.2 release of Spring does as well), however what is important is I didn't have to create an IResource to initialize an XmlObjectFactory to begin requesting services (again there are some shortcuts in Spring as well but lets continue on). Custom backing stores can be defined for the configuration by deriving from MementoSource in StructureMap. Something that I think is important to note here is that if you aren't using generics, you will request a particular service via a Type, which is different from Spring in which you provide a string as the look up key within the configuration. In my opinion this is nice as it gives me compile time confirmation that I am requesting a type that exists, whereas I could possibly misspell the string if I were using Spring and the compiler wouldn't skip a beat.

Another nice aspect about StructureMap is the ability use attributes to decrease the amount of configuration data that needs to be stored within an XML file. One of the major complaints with Spring is the excess configuration information. This also allows for code to be refactored without making changes to the configuration file. Also, configuration data can be broken up into several config files or even stored as embedded resources. StructureMap comes with StructureMapExplorer as well as StructureMapDoctor to help diagnose problems. I did have to apply the [STAThread()] attribute to the Main method for the StructureMapExplorer code, without that, an instance of the AxWebBrowser could not be created and the application would crash. Since they are targetting .NET 2.0, maybe they will consider using the new WebBrowser class? Overall Jeremy Miller and Jeffrey Palermo have created a very nice product, well worth checking into for your next design.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Extending Enterprise Library 2.0

Thursday, 20 April 2006 18:33 by nickp
Brian Button, formerly of the Patterns and Practices team just held a webcast covering how to provide custom design time extensions to the Enterprise Library console. I missed his session, however after reviewing the slide deck which he has provided, extending Enterprise Library appears much easier than when I had to do it only a year ago. Definitely worth checking out if you would like to integrate your own custom extensions within Enterprise Library.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

ROI for Agile Methodologies

Wednesday, 1 March 2006 23:12 by nickp
A common question I have heard regarding the use of agile methodologies is how can I determine the ROI of our new found practices. ThoughtWorks, an IT consulting company heavily involved with the agile movement has commissioned Forrester Research to perform an assessment of their processes; here you can read about their results.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   Agile | Software | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Test Driven Development on Google Groups

Saturday, 3 December 2005 01:05 by nickp
I have recently created a Google group for test driven development. If you want to discuss test driven development, regardless of the technology, feel free to stop by and join in!

http://groups.google.com/group/test-driven-development

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   Design Patterns | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Difficult Code to Test

Thursday, 3 November 2005 13:49 by nickp
In preparing for the December presentation on Test Driven Development for the Iowa .NET User Group, I would like to get a little feedback relative to your current testing environment. Specifically, what type of code do you find most difficult to test? Please feel free to leave feedback and I will try to address these issues during the presentation.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   .NET | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed

Data Driven Unit Tests in .NET 2.0

Thursday, 27 October 2005 00:48 by nickp
The new unit testing namespace provided with .NET 2.0 includes support for data-driven testing which is a great help when writing unit tests that deal with data access, or at least database access as it appears. The framework provides the DataSourceAttribute to specify your data source (fairly obvious), however, this attribute is really only designed for database access. What if my data source were an XML document or a 3rd party web service? Obviously there are other ways to access an XML document or a web service, such as through the Properties property of the TestContext. I'm just surprised the attribute wasn't called DatabaseAttribute. Thoughts?

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories:   .NET | TDD
Actions:   E-mail | del.icio.us | Permalink | Comments (0) | Comment RSSRSS comment feed