Posts Tagged ‘c#’

Fun with Closures in C# 2.0

Thursday, June 22nd, 2006

One of my favorite features in C# 2.0 are the anonymous delegates. Your code starts to almost look like ruby :). But hold on, they can be tricky.

Can you find the bug here?

Button[] digits = new Button[] {Zero, One, Two, Three};
for (int i = 0; i

Give up?

After executing this code, clicking any button would result in this ClickDigit being called with the value of 4 instead of the appropriate value between 0 and 3.
I groaned when I realized what it was. ClickDigit gets called with i in the state it is in when the button gets clicked – not when the event handler was attached.

Once you realize this, it’s very simple to fix it, even if it looks kind of strange.

So it should be :

Button[] digits = new Button[] {Zero, One, Two, Three};
for (int i = 0; i

Intelli J For Dot Net Is Out

Tuesday, February 17th, 2004

Jet Brains are calling it Resharper. I’ve been waiting, drooling, for a year over just the rumors that such a thing was in development.

Be warned, it’s the first cut of a first cut of a first cut. It throws lots of exceptions, and has a very small subset of intellij’s features. If you’re looking for a polished product, wait a bit, it will come, but it’s not here yet.

However, I damn near cried when I typed ‘AssertE’ control-tab, and it completed it ‘!AssertEquals();’ putting my cursor in the middle of the the parens. I love the Jet Brains guys. For my part, I’m going to use it, and submit bugs, and help them turn out another product that puts the rest of the industry to shame..

To download it or even just check it out – user/password is eapuser/eapuser

Using NFit

Monday, August 25th, 2003

So I’ve started committing some of the tweaks I’ve made to the .net version of FIT into
the sourceforge project Steve Freeman and I started at
I’d like to talk about how my team structures its code around FIT.

For context, this is a c# project, and we’re using VS.Net, NAnt, and !SLiNgshot to build, along w/ the usual suspects:
NUnit, !CruiseControl.Net, etc.

Directory Structure——
We have a directory structure that looks like :

  • doc/
  • Iteration1/
  • .html – all tests associated w/ a story
  • .html
  • Iteration2/
  • .html
  • Iteration3/
  • stories.html – list of all stories in an !AllFiles like fixture
  • lib/
  • src/
  • project 1/
  • project 2/
  • fit/
  • run.aspx – copied from nfit
  • custom fixture 1.cs – fixture used in a fit test
  • custom fixture 2.cs
  • project 3/
  • foo.sln – solution file

We’ve argued a lot over what the structure of the source should look like on a .net project, and our current solution is a src dir, inside of which is one dir for each project and a solution file. It’s flat and easy to see where everything is.

All the FIT tests go into the doc dir. fit is a VS web project that references all the other projects, along w/ the FIT dll’s. It includes all the fixtures our tests will need and the run.aspx file from NFit.

Running FIT Dynamically——
We’ve found it totally necessary to be able to run fit tests dynamically in addition to
running them from command line. Ward has his run.cgi on to let you click ‘run’ on a fit test. I’ve just checked in Run.aspx into NFit which will let you do the same thing.

This is how we use it:

We have 2 webshares. */doc* points to our ‘doc’ directory and holds all the tests. */fit* points to our ‘src/fit’ directory and holds our copy of Run.aspx along w/ all the code our tests run against. We put a run link at the top of each test that points to ‘/fit/run.aspx’, and when we browse our tests we do it through our local IIS using something like ‘http://localhost/doc/stories.html’.

Because fit is just another project along w/ all our other projects in VS, we get linking,
debugging, and building for free inside and outside visual studio.

Structuring FIT Tests——
When you’re writing so-called ‘acceptance tests’, it’s important to remember that there are several different missions of testing and types of tests to achieve them. The way you structure your tests should reflect this, see default.WhatAboutAcceptanceTesting

In the doc directory, we group our tests in files by the story they test against, and the stories by the iterations they are completed (or scheduled to be completed) in. This of course makes the assumption that all tests “belong” to one and only one story. Up until now that’s been okay, we’ll probably add another place to put tests when and if that becomes a problem. It has been good to teach our team to think about testing functionality in terms the customer can see.

Now we could just run all our tests automatically, but we wanted one page that everyone could
go to to see our teams status. So we take the spreadsheet of stories that our client keeps complete with
their points, their iteration, and their status (done or not). And we point to it with an aspx page to
provide an html view that fit can run against. So when you go to http://localhost/doc/, you see a table for
every iteration, each of which contains all the tests in that iteration. Only ones that have been marked
done in the spreadsheet get run.

So we have one page that tells you the status of all stories we’ve ever done. And it tells you how we’re doing
on the current iteration as well – along w/ our velocity of course :)——How about if my return value is an XML document, how does FIT deal with that. How do I pass two parameters to a method.


– Yazid Arezki