Jeremy D. Miller -- The Shade Tree Developer

Can you explain more (or point me to a reference) about how you would drive the tests with Ruby, specifically in reference to WinForms app?  I'm not familiar with this.

Thanks!

Jeremy

FITnesse?

You've hit the nail on the head.  FIT tables seem to be great for testing... well, tabular data.

We are still using FITnesse to drive conversations with the product owner as well.  Just last week, we sketched something out in FIT tables, then had a conversation with the PO to clamp down what he wanted.  After that, we set about making what was a sketch into a test that passes.

When we get away from using FIT for sketching out ideas, it will most likely be in a move to use Groovy.  This may happen as early as a couple of weeks from now.  We'll probably still us FIT for discussing things with the PO.  But, you're right, it's pretty clunky.

@Jeremy

Gotcha, I'll be waiting :)

Jeremy

I experimented using Powershell because it is a scripting (dynamic) language that has access to .NET libraries (2.0) - and it has some funky syntax that makes it simpler to work with than even NUnit in some cases.

Then I added some testing primitives to make it easier for writing acceptance tests, tabular or otherwise.

See more at www.codeplex.com/psexpect.

We've started to use more BDD-style requirements using stories and scenarios, with "Given...When...Then" syntax.  In the future, I'm looking more towards RBehave, as it can closely match the original story conversation.

In the meantime, I'm working with Joe Ocampo (http://www.agilejoe.com) to produce something similar to RBehave that we can use in an arbitrary test framework.  We wound up creating very similar frameworks, and we're now joining them into Behave# (www.codeplex.com/behavesharp).

I still can't get over the clunkiness of Fit personally.  I think the problem is that code approaches were clunkier because the syntax of the code obscured the intention of the tests, especially to business owners trying to understand the tests.

DSLs using more expressive languages, whether it's Ruby or Boo or whatever, seem to obscure intent the least.  Anything that gets us closer to the language of the business will win out eventually, I think.

The idea of Fit testing is great.  The tools in practice drive up maintenance costs.  In my experience, the increase in the effort to maintain Fit/Nesse tests increase exponentially in relational to the volume of tests and test code.

I think that mata-programmable DSL's are a good avenue to explore.

I've written a few notes about my experience with FIT here: nat.truemesh.com/.../000702.html.

I think the *idea* behind FIT is excellent and one of the most promising directions that exists for improving the communication between non-technical users/customers and developers.

However, the implementation causes a lot of problems.  The framework design, especially how reflection is used, makes it very expensive to maintain FIT tests and maintain code that is specified by FIT documents. Its "cathedral" style of free software project management means that user feedback is not fed into the design of the framework fast enough.

However, I don't think that dynamic scripting languages are going to be the answer.  They don't really address communicating with non-technical users and they still require reflection or other glue code to link the script interpreter to the application under test, so there's still maintenance overhead.

I'd like to see a radical redesign of the FIT framework.  Most of what's in the FIT framework can be replaced by existing open source libraries: JUnit for running the tests, TagSoup and XOM for parsing and generating HTML, etc.  FIT should provide a clean object model model for extracting test data from tables, lists and other HTML structures and annotating those structures with test results.  It should reduce the use of reflection (the most baroque of which is in FITLibrary, admittedly) and ensure that the links between the HTML and Java better support refactoring and diagnosis of failing tests.

we have done fit off and on for a while now.    But for the most, unit testing frameworks can do mostly what we want at an acceptance testing level.

However Rick Mugridge is working on http://www.zibreve.com  which might be interesting, and I know Rick has some interesting ways of making FIT do some cool things.

We have used FIT a few times, because we liked the idea of subcutaneous layer testing, but I can't help but feel like Scott that the tool set produces tests that are sometimes fragile and sometimes over constrained by the tabular format.

Unless you have a strong customer-authored test requirement it seems easier to drive layer testing with an xUnit tool and write tests in the same language that you code in.

Because we tend to have a hexagonal architecture, when we need to be able to have variable test inputs so that we can test differing 'acceptance' criteria we have tended to find it easier to use a custom test harness, built in WinForms, as a front end to provide those inputs that performs the layer test. In other words we riff of the FIT testing idea, but use our own engine instead of using FIT. The cost here doesn't tend to be material in a larger project, but I guess smaller projects could find it hard to justify the cost of a write your own layer testing tools approach.

I have not seen the use of Ruby that you are specifically talking about, but I guess you must either be talking about driving the UI using Ruby or writing a DSL-like script in Ruby to define tests. I think those are possibilities; but if those tests drive the UI then they will tend to suffer from the fragility of UI tests and thereby miss on some of the benefits of layer testing as an approach.

Of course there may be a sweet spot for early use if IronRuby in being able to combine the expressiveness of scripting languages with easy subcutaneous testing of .NET projects, and it would be a good way to get Ruby skills into the Enterprise..

Pingback from  Musings of a Software Development Manager  » Blog Archive   » Future of FIT/Fitnesse

I feel the pain. I'm dealing with helping guys (and girls) out on writing fit tests here and there's a lot of perplexed looks and crazy fixtures happening. I still have some faith in fit and it really does a good job at some tasks (although if your users are writing fit tests that duplicate unit testing, they're going down the wrong path).

For me though I'm groking BDD right now and how different (easy/hard) it is to do using something like Behave# vs. Fit. Blog posts to come shortly on all of this as I'm playing in the sandbox this week.

Pingback from  Scott’s Blog » Is Fit Testing Dead?

I've had doubts for months, but I think I finally soured on Fit testing within about 5 minutes last

How do I apply RowFixture with junit in RAD .. Please explain with a simple program.