Are you using C# and FitNesse? Considering moving to FitNesse.Slim?

I eventually plan to port several FitNesse.Slim tutorials written in Java to C#. It’s a bit of work so I want to make sure there’s enough interest now (this is about when not if). Given that C# and Java are similar languages, I’m not convinced it’s really necessary right now. I’m under the impression that the user base for FitNesse.Slim + C# is small, but I’m often wrong. I have other things I want to get around to writing, so I’m trying to get a temperature reading to know what might be useful next.

• Just the basics, all the tables and an example of each (quick to do)
• Something more comprehensive, building story tests and working through to TDD to build a system from the ground up?
• A full porting of the existing tutorials as is?
• ...

I’m really looking for some user stories from some actual candidate users. If that’s you or you know someone and you like being a proxy, please respond.

Thanks!

Brett

It was an interesting week at JavaOne, with lots of talks and hallway discussions about new languages on the JVM. One of those languages is Clojure.

Rich Hickey, the creator of Clojure, gave a talk at the Bay Area Clojure User Group Wednesday evening. During the Q&A part, he said that he’s not big on writing tests, although he always runs the tests that other people have written before he commits changes.

This week is JavaOne in San Francisco. The Bay-Area Scala Enthusiasts (BASE) held their monthly meeting. Martin Odersky, the creator of Scala, was the special guest. He discussed what’s new In Scala 2.8, followed by Q&A. We met at Twitter HQ.

These are my notes, focusing primarily on Martin’s presentation, and filled in afterwards with additional details. Any transcription errors or erroneous extrapolations are my own fault. It’s also late in the day…

Some of the features are not yet in the SVN trunk, so don’t assume my examples actually work! See the scala-lang.org for more details on Scala 2.8 features.

There are a few more months before it is released. A preview is planned for July, followed by the final release in September or October.

So I’ve written a somewhat ugly method with the intent of having people clean it up. Want to give it a try? Post your results and then I’ll show what I ended up doing in a few days (or after the activity dies down).

It’s in Java, but feel free to post in other languages. I’d be interested in seeing something in whatever language Michael Feathers happens to be deeply studying right now!-)

Oh, and if you feel like going “overboard” and using a few design patterns just because you can, I’d like to see that as well.

Here it is:

  public void take(int v) {
    if (currentMode == Mode.accumulating) {
      int digits = (int)Math.pow(10, (int)Math.log10(v) + 1);
      int x = stack.pop();
      x *= digits;
      x += v;
      stack.push(x);
    }

    if (currentMode == Mode.replacing) {
      stack.pop();
      stack.push(v);
      currentMode = Mode.accumulating;
    }

    if (currentMode == Mode.inserting) {
      int top = stack.peek();
      stack.push(top);
      stack.push(v);
      currentMode = Mode.accumulating;
    }
  }

Bob Koss and I are teaching an XP Immersion this week and he’s going to be using FitNesse with both .Net and Java. It’s been some time since I checked the instructions or updated to the latest Slim.Net component.

• Using Slim .Net in FitNesse
• FitNesse Tutorial 0, C# Details

Comments and corrections welcome!

Recently I was lamenting how much I liked Moq for C# and its API. I like that is uses lambdas and generics and I think both the interface and general approach are great.

Someone I follow on twitter, @tieTYT, suggested that I should give Mockito a try. It is a mocking library for Java, written by Szczepan Faber and friends.

Well I gave it a try and I found it to be an excellent Mocking framework similar in spirit to Moq and it worked well while not requiring lambdas.

• Develop something using TDD.
• Using a mockist approach
• Use Inversion of Control
• Refactor code to use the GoF state pattern
• Refactor code to use the GoF Template Method Pattern
• Fix the code to avoid violation of the Liskov substitution principle (this is in there though not currently emphasized)
• Fix the code to avoid violation of the Dependency Inversion Principle.
• And as a side benefit, by using a TDD approach you’ll naturally avoid violating the Law of Demeter (though you will introduce some feature envy).

Have fun and please comment. You can also view a printable version.

FWIW, I learned Mockito and wrote this tutorial in about a single work day, so it was pretty easy to pick up and use. I suspect my recent experience with Moq gave me the mental model and then it was just a matter of syntax.

A few blog articles ago I showed some examples using Moq. I created those examples in anticipation of using Moq in a TDD class with a group in Canada.

What I ended up creating was different for a number of reasons. The final version is somewhat cleaned up compared to those first examples, so here are those examples as well: actual test class created.

These tests are not really that different from the first version, other than I did not use exceptions as much.

• Creating one test at a time
• Write the underlying service
• When all tests are passing, try to refactor to the state pattern.

It’s a good exercise. The guys in Canada seemed to really grok Moq and started using it to characterize their actual code the next day.

This week I worked with a great group in Canada. This group of people had me using Moq for the first time and I found it to be a fine mocking tool. In fact, it reminded me of why I think the Java language is now far outclassed by C# and only getting more behind (luckily the JVM has many languages to offer).

• Replace switch with polymorphism
• Replace type code with strategy/state
• Introduce Instance Delegator
• Use a combination of template method pattern + strategy and also strategy + composite

This is actually pretty standard stuff and this group understands the way forward. But what of their existing technical debt?

If you go here you’ll see that I struggle to keep the CRAP out of FitNesse. Despite the whimsical name of this metric (which I take a perverse delight in), I find it to be remarkably useful.

CRAP is a metric that is applied to each function in the system. The formula for CRAP is: CRAP = comp(f)^2. X (1 – cov(f)/100)^3. + comp(f)

Where comp(f) = the cyclomatic complexity of the function f. and cov(f) = the unit test coverage of function f.

So a function’s CRAP will be small iff the cyclomatic complexity is low and the test coverage is high. CRAP will be huge if cyclomatic complexity is high, and there is no coverage.

What does this have to do with architecture? Read on…

This week I’m working with a customer that uses two tools I have not previously used: MBUnit (instead of NUnit, and it is now part of Gallio [sic]) and Moq (by Daniel Cazzulino).

For how I’m using MBUnit, there are no differences (that’s not to say it’s the same as NUnit, I’m just using it that way). However, Moq is a different mocking framework.

While you can do something similar to a record/playback approach, Moq encourages a different approach. Rather than try to describe it, I’ll show a few examples and you can decide for yourself (or you can tell me how I should have done it better).