blog.fossmo.net

Everyone is into TDD these days. Right? If you want to call yourself a serious developer, you need to write unit tests. Blogs and seminars are filling your head with: "TDD or loose your night sleep". "TDD or write tons of documentation". "TDD or have a crappy design". I could go on forever...
Developers are eating this information provided raw, looking for the silver bullet.

"Everybody is doing it, so I have to do it too".

I guess if you are a teenager, this is a very valid argument. It's hard to stand out of the crowd at young age. Just follow the rest and everything will work itself out.

But, your not a teenager, right?

I guess what I'm trying to say is; look into the pros and cons before deciding to start using it. Read some scientific research. You have a much better chance of succeeding then, as everything else in life.

I posted a question on an up and coming Q & A site called Stackoverflow. I asked if someone could point me to some information about scientific research done on TDD. I got one lousy answer and the guy answering just goggled for the answer. No one knew. I find this a bit disturbing. A lot of people throw themselves into TDD head first. Doing this was okay 6 years ago, when TDD was in its modest beginnings. But, not today. You can find a lot of scientific research on this area this days. Try goggling for it.

Does it really matter if you don't know of any research done in this area?
Probably not. If you really enjoy something, the chances are that you are good at it, and you should continue doing it. Blissfully ignorant. On your home projects. But, if you have swallowed the red pill and want to expand your use of TDD from your hobby project at your basement, and into your organization, you should know something about the research done in this area. How can you put up a good argument for TDD if you can't referee to good sources?

It's like going in to a wage negotiation with your boss and say:
"I want a higher salary!"
"Why?"
"Because!".
"Because, what?"
"Because!"
"Get out of my office!"
"But...."

This won't get you the 50" wide screen TV you always wanted, for sure!
You need some hard facts. A good starting point are these papers:

http://users.csc.calpoly.edu/~djanzen/pubs/janzenTDDSoftware08.pdf
http://iit-iti.nrc-cnrc.gc.ca/iit-publications-iti/docs/NRC-47445.pdf
http://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf

Tags: tdd

I'm going to speak at a seminar held by Dataforeningen in Trondheim. The topic for my session is "Unit testing from the trenches". Another speaker is, among others, Aslak Hellesøy who is going to talk about Behavior Driven Development. Lets hope I'm not to jet lagged. I'm going to PDC, and will be back two days before the seminar :-)

Tags: dataforeningen, speaker, testing

I have used Cruise Control from ThoughtWorks at my CI server for a long time. CC.NET is a very good tool, but you have to spend a lot of time messing around with XML and tasks. It's time consuming. I have heard a lot of positive things about TeamCity from Jetbrains, so I figured that I wanted to try it. And, yes Jetbrains is the same company that makes ReSharper. A wonderful tool. I started out installing TeamCity on my server, and everything went like a breeze. I had my test project up and running within 10 minutes. Very easy configuration due to the web GUI. All good, BUT MY TESTS DID NOT RUN! I searched the Internet and could not find a good answer to why the tests did not run. I finally started to look at my build file, and it turns out that I imported my MSBuild community tasks this way:

This makes TeamCity very sad, and it won't display the test results. What TeamCity accepts is this:

So, the tip is: stay away from importing your tasks by using <UsingTask> tag, and rather use <Import>.

Tags: teamcity; continuous integration

Ncover is no longer free, and if you want to use code coverage in your build scripts, without paying for it, you need to find another solutions. In my case, this solution is partcover. It works pretty much like Ncover do (did) and you can include it in your MSbuild scripts to cover unit tests. Partcover uses some COM stuff and needs to be registered (you can of course install the msi on every computer you run partcover on and the problem is solved). I prefer that all the tools I use together with my build scripts, work without me installing anything. Adding the target shown below to your MSbuild script will make it possible to use partcover without installing it.

What it does is to register the PartCover.CorDriver.dll before partcover is run, and unregister it after partcover is run.

To run this script you need to run under administrator privileges.

Tags: partcover buildscripts

It took me some time to figure this out, but I finally got it.
If you in RhinoMocks want to create a mock based on a interface, the syntax is like this:

IMyInterface myObject = mock.CreateMock<IMyInterface>();

myObject is now a mock object.

When using Moq (mock-you) mocking framework, you have to add .Object to the mock to get the object.
This syntax I don't find very intuitive.Below is a example of a test using Moq (without Expectations):

[TestFixture]
public class MyTestClass
{
   [Test]
   public void MyTest()
   {
      var mockedTestInterface = new Mock<IMyInterface >();
      MyClass myTest = new MyClass (mockedTestInterface.Object);
   }
}

I guess it will take a little time to get used to the syntax. But, that said,
I really like this framework.

Tags: moq

Thoughtworks have released a project called "White" which is a UI Testing framework for WPF, WinForms, Win32 and SWT (Java). How cool is that? ;-) I haven't tried it yet, but one of the following days I'm going to look into it. It looks very promising. I'm going to post all about it when I have tested it.

Link to the project page

Tags:

I have used Model View Presenter (MVP) a lot the last months. It's a great pattern, but a lot of the people I talk to have problem understanding how it works, and how to use it. I will try to explain it simple in this blog post.

Passive View and Supervising controller
The creator of MVP, Martin Fowler, spilt the pattern into to new patterns. This was due to apparent confusions between Model View Controller and MVP. The new patterns is called Passive View and Supervising Controller. The main difference between this to patterns, is that Passive View puts all the view update behavior in the controller/presenter and Supervising Controller encourage the view to do most of the updating itself, and only brings in the presenter/controller when there's more complex logic involved. In my example application later in this blog post, I show Passive View.

When to use it
MVP is a great pattern to ease up unit testing the graphical user interface (GUI), and to decouple the GUI from the underlying model. MVP makes switching GUI a breeze.

Explained graphically
MVP is a pursuance of an other pattern called Model View Controller. In MVP, the view and the model don't know of each other, but in MVC the view knows of the model, and gets its updates from it.
I will cover MVC in a later post.

The figure below visually illustrates the pattern.

More thoroughgoing, this is what happens:

1) The user executes a action. The action is forwarded to the presenter.
2) The presenter asks the database (model) for the data to view.
3) The model sends the data back to the presenter.
4) The presenter updates the view with the new data.

There are normally four main classes used in the MVP pattern. To be more specific,  three classes and a interface; the view, typical a WinForm, WebForm or XAML-file. The interface, witch describes the fields in the view. The presenter, witch executes the views actions and communicates with the model. And, of course,  the underlying model, e.g. a database.

Example application
I have created an application witch displays name, e-mail, state, etc. The application uses the MVP pattern. This is what the application does: You enter a name into the search text box and the program reads information from a textfile. Information about the user is displayed in the form. 

 
Shows the GUI in the application

Project
The solution consists of three projects. One view, one presenter and one model. If you wanted to have several forms, you would have to create more presenters and views. 

Shows the project structure

Interface
Let's look at the interface. It's found in the presenter project, and is named IPerson. It includes all the fields I want to display in the view.

The last field in the interface is Message. You will find it in the lower part of Form1, displaying: "Data fetched.". If any error occurs in the application, it's shown there. The class Form1 (Form1.cs), implements the interface.

   

Form1 implements all the properties in the interface. This is, as you know the startingpoint of the application. A instance of the presenter is created in the view. This way the presenter and view can communicate, and the presenter can update the GUI elements.

Shows some of the properties in Form1

When the search textbox is filled with a name, a event is triggered. It ends up in the method txtSearch_KeyUp in the class Form1:

The presenters constructor, inputs the view and the class fetching data from the model, as parameters. Hence, the presenter has access to the view and the model. This way of doing things is called Dependency Injection.

In the method UpdateData (called from the view), data is fetched from the datasource, and the view is filled with the returning data. If a exception occurs the field message, in the view, displays the error message. If nothing happens, the field displays "Data fetched.".

In the model (Data project), data is fetched from the file and put into a person object. Person object is returned to the presenter. If no data is found, an exception is thrown (witch is displayed in the message field in the GUI).

That is the course of events in the Model View Presenter pattern.
I recommend you to fire up Visual Studio and debug the sample application.

If you want to download the sourcecode for this example, you can find a link below.  

Tags: dependency-injection, model-view-presenter

A great tool for generating testdata online is this site: generatedata.
It's a easy and quick way to generate simple testdata to put in databases, flatfiles or Excel-files.

Tags:

Visual Studio 2003-2008 Express are missing Add-In support and no ability for the debugger to attach to a process.

This brings up a problem when trying to debug your tests with Nunit. After Testdriven.NET no longer supports the express editions, we no longer have the possibility to run tests against code we develop in the express editions. Well, so it seems.

But, there is still a way around this. It's not as smooth as Testdriven.NET, but it works all right. In the folder which contains the test library you want to debug, add a file named the same as the project, but with the extension ".csproj.user". This is the content of one of my files:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Nunit|AnyCPU' ">
    <EnableASPDebugging>false</EnableASPDebugging>
    <EnableASPXDebugging>false</EnableASPXDebugging>
    <EnableUnmanagedDebugging>false</EnableUnmanagedDebugging>
    <EnableSQLServerDebugging>false</EnableSQLServerDebugging>
    <RemoteDebugEnabled>false</RemoteDebugEnabled>
    <RemoteDebugMachine>
    </RemoteDebugMachine>
    <StartAction>Program</StartAction>
    <StartArguments/>
    <StartPage>
    </StartPage>
    <StartProgram>tools\nunit\nunit.exe</StartProgram>
    <StartURL>
    </StartURL>
    <StartWorkingDirectory>
    </StartWorkingDirectory>
    <StartWithIE>false</StartWithIE>
  </PropertyGroup>
</Project>

I have created my own solution configuration in VS.NET called Nunit. It is used when running the tests.
You can of course use the default configuration; DEBUG if you want to. Then you have to change a line in the content:
 '...$(Platform)' == 'Nunit|AnyCPU' ">'

to

'...$(Platform)' == 'Debug|AnyCPU' ">'.

This worked perfectly for me.

Tags:

For de som ikke har penger til å kjøpe Microsoft sine mer avaserte versjoner av Visual Studio 2005 og ønsker å benytte seg av unit testing og code coverage er verktøyet TestDriven.NET et bra alternativ. Pakken inneholder verktøyene Ncover og Nunit (og noen andre test rammeverk) og integreres automatisk i Visual Studio 2005.

Tags: