Object Mentor Blog: Tag slim

Quick Intro To BDD Style Table Syntax

Brett Schuchert — Tue, 21 Sep 2010 23:54:00 -0500

Here it is a over a year after I wrote several FitNesse tutorials. Several months back Bob added some new ways to write scenarios using a placeholder syntax and an alternative way to render script tables. What you end up with is something just a little less table-like.

This is a very quick and dirty writeup I’ve been meaning to put together for nearly half a year. So while it’s not pretty, it works, shows the basics and may make you aware of something you didn’t know was there – unless you’ve been reading the release notes.

Alternative Script Table Syntax

Comments and requests welcome.

Brett

Slim table examples with fixtures in C#

Brett Schuchert — Mon, 08 Jun 2009 23:15:00 -0500

There was not a lot of interest in a series of tutorials. Some, yes, but not very much. So I’m not going to be spending much time right now writing FitNesse.Slim tutorials for C#.

However, I think it’s a good idea to at least have some examples of each of the tables so those few that are so inclined, have something from which to start.

Have a look: C# Slim Examples

Calling C# and FitNesse Users

Brett Schuchert — Sat, 06 Jun 2009 00:43:00 -0500

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.

If this would help you or your team, what would you like to see?

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

FitNesse.Slim Scenario Shenanigans

Brett Schuchert — Mon, 16 Mar 2009 23:25:00 -0500

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.

Getting Started with FitNesse in C#

Brett Schuchert — Fri, 13 Mar 2009 01:45:00 -0500

The tutorial I mentioned yesterday now has a Java path and a C# path. Check out http://schuchert.wikispaces.com/FitNesse.Tutorials.0.

In addition, you’ll need to get Slim.net. Check out here: http://schuchert.wikispaces.com/Acceptance+Testing.UsingSlimDotNetInFitNesse.

FitNesse.Slim table table example and migration to a DSL

Brett Schuchert — Mon, 23 Feb 2009 06:03:00 -0600

I’m working on some notes related to an upcoming presentation. You can see an example of using the Slim table table here: Table Table Example

It’s a work in process. If you see something that doesn’t quite make sense, please let me know.

!define TEST_SYSTEM {fit:A}

Brett Schuchert — Mon, 03 Nov 2008 18:08:00 -0600

Uncle Bob has been busy with FitNesse lately. If you have been following him on Twitter or if you read his blog post on the subject, then you are aware of his work on Slim.

This post, however, is not about that. It is about something he did to make it possible to execute different tests in different VM’s.

By default, when you click on the test or suite buttons to run tests, FitNesse finds the tests it will run and executes them in a single VM.

If you want to select a particular test runner in FitNesse, you can add the following to a page:

!define TEST_SYSTEM {fit}

Or you could add the following:

!define TEST_SYSTEM {slim}

If you do not define this variable, then fit is the test system used to execute tests, making the first example redundant…almost.

These variable definitions are inherited. FitNesse will search up the page hierarchy to find variable definitions. If you do not define TEST_SYSTEM anywhere in a page’s hierarchy, then that test will be executed with fit. However, if any of the pages above the current page changed the runner to slim, then Slim will be the test runner.

The other thing that you can do is add a “logical-vm name” to the end of the runner. Here are two examples:

On some page

!define TEST_SYSTEM {fit:vm1}

On a different page

!define TEST_SYSTEM {fit:vm2}

All tests under the page containing the first define run in a vm with the logical name vm1. The same is true for vm2.

By default (i.e., you have not defined TEST_SYSTEM anywhere), all tests are run in the same vm. More precisely:

When you click the test button, all tests executed as a result of that button click run in one VM.
When you click the suite button, all tests executed as a result are executed in the same VM.

As soon as you introduce the TEST_SYSTEM variable, the tests might execute in the same VM or different VM’s.

Conceptually, there’s a default or unnamed VM under which all tests execute. As soon as a page contains a TEST_SYSTEM with the added :VMName syntax, that page and all pages hierarchically below it run in a different VM.

If for some reason you want to have two unrelated page hierarchies execute in the same VM, you can. Define the TEST_SYSTEM variable with the same logical VM name.

Why did he add this feature

I asked him to. He was working on that part of FitNesse so I figured he’d be able to add the feature for a project I’m working on.

It has to do with service-level testing of a SOA-based solution. If you’re interested in hearing about that and the rationale for adding this feature to FitNesse, let me know in the comments and I’ll describe the background.