Using FitNesse rather than NUnit

Question

As I've understood it, there's a couple of cases when you may want to use FitNesse.

• You want to do acceptance testing rather than unit testing.
• You want to use it as a communication tool with the stake holder.
• You want to do large scale tests rather than granular tests.
• You want non-technical people to write the tests.

My personal opinion and experience is:

• I can do acceptance testing using tools such as NUnit. Fitnesse is basically just a framework for calling public methods on a .NET assembly, which can be done using NUnit to.
• The stakeholders tell me what they want. They are rarely interested in writing Fitnesse tests. They seem to have other/better/more important things to do.
• You could do large scale tests using FitNesse. As far as I know, you would have to enter all input for these large scale tests into a plain text editor in a web browser. How would this be easier than reading the input data from a text file on disk, or an excel file or a database? Sure, you could specify the path to the file on disk in the web interface, but what benefit would this give over using NUnit to read that same file?
• These non-technical people have to write code following a very specific syntax in a text editor on a web site, which will call .NET assemblies later on. The .NET code gets messy, since the non-technical person doesn't know programming but he's still specifying how the assembly should work.

Can someone share some other opinions on the subject? How have FitNesse been valuable to you?

Answer 1

The typical answer for your question is

"Higher level tests (such as acceptance) are great until you find the problem. At that point if you don't have unit tests then the only thing you know is that something is broken--not specifically what is broken or where the fix should be applied."

Answer 2

FitNesse is designed for a wholly different purpose than NUnit. Doing acceptance testing with NUnit means, first of all, that the entire test suite has to be written in code. FitNesse is designed with the intent that you can, given a certain level of preparation, write your tests in data. These are very different modes of operation, and they apply to very different resources. They also encourage very different views of the world - a FitNesse test case designer is working on the assumption that a very simple, straightforward transformation is going to happen, whereas an NUnit user has a great deal of knowledge about how that transformation works and has hooks into the system which have nothing to do with the transformation itself.

If you can't get stakeholders to write use cases and functional tests, then you need a stand-in for those stakeholders, which is where a traditional QA department comes in. Not having a stakeholder to do this stuff isn't an excuse for not doing it.

The benefit of using FitNesse to read your data over a custom format is pretty simple: It's a standard way to enter test cases. If you don't see the benefit in that, perhaps you need to spend some time going down the path you describe, because eventually you're going to hit some walls and maybe they'll help you understand.

Answer 3

So yes, you could write Acceptance tests in nUnit. but that misses the point. Fitnesse is supposed to be an alternative UI to your application that expresses a detailed flow of assertions:

The user does this The user does that the user now sees this

Ideally the fitness layer is capable of sitting directly over the very top level of your app. basically just replacing the final rendering layer.

unit testing tools just are not really designed for that, can you do it? sure. But it's weird.

Another thing I think your a bit off on is the idea that "You want non-technical people to write the tests.". Fitnesse is a tool for collaboration. You should be writing the tests WITH the stakeholders, giving and getting feedback. Then it has the bennifit of being the documentation. So a year later, when someone wants to know why the system works the way it does, you can pull up the test...displayed in a way a BA can understand (unlike nUnit)...and say well, here it is, should we change it?