There is now a 4th FitNesse tutorial at: http://schuchert.wikispaces.com/FitNesse.Tutorials.ScriptTables. As the URL suggests, this is about Script Tables.

Next up: Scenario Tables and then Table Tables.

One other change, each of the 4 first tutorials now have source available at github along with tags:

• FitNesse.Tutorials.0.Start
• FitNesse.Tutorials.1.Start
• FitNesse.Tutorials.2.Start
• FitNesse.Tutorials.ScenarioTables.Start
• FitNesse.Tutorials.ScriptTables.Start

So you can start at any of the tutorials rather than having to work your way through each one from the beginning. (Of course, that last tag is my starting point for the next tutorial, which will take a few days to update and add to this sequence of tutorials.)

Comments/suggestions/requests please.

Here is another tutorial for FitNesse: http://schuchert.wikispaces.com/FitNesse.Tutorials.2.

This tutorial and the first now all fit together and form one ongoing example. If you work though the first three tutorials at: http://schuchert.wikispaces.com/FitNesse.Tutorials, you’ll have practiced:

• Using Decision Tables
• Using Query Tables
• Refactoring within FitNesse
• Using SetUp and TearDown pages
• Understanding inheritance of SetUp and TearDown pages
• Basic test organization under a suite
• Switching into unit testing from acceptance testing

In the early ‘70s F. T. Baker, and Fred Brooks wrote about the notion of Chief Programmer teams. The idea was that a highly skilled chief programer would be assisted by a team of helpers. The chief would write most of the code, delegating simpler tasks to the helpers.

Though the idea was tried at IBM and shown to work well, the idea has never really caught on. One reason may be that the economics don’t appear to be all that good. A team of four juniors making $50K supporting a senior making $100K costs $300K. That just seems like a lot of money for one well supported chief programmer writing most of the code.

But in light of the movement towards software craftsmanship, perhaps it’s time to dust off this old idea and look at it from a different perspective. Consider the following thought experiment…

There’s a new tutorial on using FitNesse decision tables: http://schuchert.wikispaces.com/FitNesse.Tutorials.1.

This tutorial is a lead-up into using Query tables (that’s the next one I’ll be writing), which will describe some code you can get from github that will turn an object/collection into a well-formed query result.

These tutorials are background for a presentation I gave at SD West 2009 and will probably be giving at Agile 2009.

Comments Welcome.

Here are several versions of the same unit tests written in different styles using CppUTest: C++ Unit Test Examples. If you look near the bottom, you’ll see what looks like story tests in C++. Shocking!

These are all based on Bob’s Prime Factors Kata.

I’m going to give Boost another whirl. There appears to be a great installer for Visual Studio. It requires free registration. I’m on the fence about what to use first and was wondering if you have any suggestions.

I’m thinking about basic things initially:

• Regex
• Threading
• Sockets

Maybe a multi-threaded server responding to message via socket, with client threads processing requests using regex?

If you have anything you’d like to see, reply to this blog and I’ll follow up with you.

1. A value is the instantaneous state of an object. – In OO languages, we have objects. In FP languages, we throw out the object and instead manipulate the values it would take on over time.
2. Algebraic data types are classes. – Every case in an ADT is a state that an “object” can be in.

   
   data Tree = Empty 
             | Leaf Int 
             | Node Tree Tree
   

   When we write functions over ADTs, we are obliged to cover all of the cases. So, for instance, if we define depth for Empty, we have to define depth for the Leaf and Node cases as well. When we do, we can evaluate depth t for any tree value and have a well-defined result.
3. The functions which we define over an ADT can be considered its public interface. – There’s a school of thought which says that encapsulation doesn’t matter in an functional programming language because values are immutable and corruption can’t happen. Nothing could be further from the truth. If we add or remove a case from an ADT all of the functions which pattern match against it are impacted. While we don’t need to have an encapsulation boundary as tight as we might have in an OO language – it pays to be conscious of how far ADTs travel in a program. Encapsulation is the act of forming a boundary by transforming an ADT into some other form of data.

Each of these statements is a lie, an artful simplification, but they are a convenient and not entirely false way of thinking about functional programming until it becomes second-nature.

Functional programming is in the air. It’s nearly unavoidable. Even if you haven’t heard people talk about it or haven’t read a blog about it, you’ve probably seen its influence in your project. People are taking ideas that they learned in functional programming and applying them in straight object-oriented code. In Java, where there are no closures, today you are much more likely to encounter someone’s hand-rolled fold or map abstraction, and even if they haven’t gone that far, you are likely to find attempts to replace mutable data with immutable data. It’s part of the learning process, and there are some interesting patterns which occur along the way.

OO programmers often think in terms of entities. They imagine objects with identity and changeable local state; messages sent to objects alter their local state and trigger further message sends. Classic OO is intrinsically time-oriented. How do we pull this into a functional world? One thing that we can do is choose to see an entity as a series of values over time. Here’s one way to do it. If we have an entity like this:

Pat Eyler posted an interview with Alex Payne and me (Dean Wampler), which we conducted over email. We dish on Scala, Functional Programming, and our forthcoming book Programming Scala.

I was working with Uncle Bob today and we came across a case where we wanted to invoke a curried method, but it was in FitNesse. It took me a while to grok it. Now I do, but it took some time.

On the surface it involves a Decision Table using a Scenario Table, which uses a Scenario Table that ultimately uses a named Fixture. It’s a bit of a long read but the results do suggest a way to express a generic test and then invoke it while reducing duplicated information.

Here’s the link: http://schuchert.wikispaces.com/FitNesse.Tutorials.ScenarioTables

This is a rough draft. I’ll be updating it over the next few days. If something does not make sense, please post a comment and I’ll update it.

For C# users: I have not tried this example using Slim.Net. It should work if you follow the instructions from the previous tutorial and simply replace the Java code with C# (not really a big deal when you see the code). In fact, C# offers a more flexible switch, so it would be a bit cleaner.