It seems to me FitNesse has the following advantages:
Let a non-technical person define sets of test data and expected results (how they define success). A non-technical person could be a user, a product manager, or possibly a software quality professional who does not have access to the source code and/or does not know how to program in the source language.
Lets the non-technical person run the tests and quickly get a sense of the health of the code under test.
I'm working with a code base where the "user interface" is an API in a library, so it is understandable and relevant only to other technical professionals who know the language and have direct access to the API. I need to choose a way to perform integration tests. I'm intrigued by FitNesse but I don't understand why I might bother. These are advantages that still apply in this case:
It enforces a standard style for defining tests, so they're easy to understand by other software professionals who need to work with the same code.
It lets the source code's author and maintainers quickly see where a test fails and how it failed.
Tests are written in the same language as the source code so a separate body of expertise is not needed (i.e. perl or python).
However, there are other simple ways to achieve those same goals, without having to leave your code editor. Also, in order to run the tests, I don't see a way to tie FitNesse tests into an automated system, such as having a continuous integration server run them with new builds. I also don't see how to run FitNesse tests on a hardware platform other than the development platform, so they would not catch timing issues.
So, if you use FitNesse in an environment where your "user" is just as technical as you are, why? If you tried it out and decided against it, what were your reasons?
If you use FitNesse to test code meant for separate proprietary hardware (an embedded system), how does that work?