Q:

Where do Fitnesse fits between unittests and API testing?

Our team writes unittests for our python projects. Besides that, we have a tool that allows us to run scripted API tests (we can make requests and evaluate the result, passing or failing the test).
I am looking for a tool that helps the team to write acceptance tests for every ticket we do (primary objective), and then store these tests to start our regression test repository (secondary objective).
The problem is that not every ticket we do is API test-able, and sometimes  I feel unittests are not enough (sometimes we need grey or black box tests). Some of our services don't have public APIs and they interact with other services in a lower level.
For example, we could have a ticket to change an internal function, but this should not affect our API response (we have tests to check this). Unittests could supposedly test this specific function, but this function can be called in other parts of our code (and even in other projects), so there's no way to write an unittest to check if this change won't break stuff across all of our services.
I was taking a look at Fitnesse and I was wondering: can Fitnesse fill in the gap between unittests and REST API testing, with the so called "acceptance tests"? What type of input/output can Fitnesse take?

A:

Full disclosure: we rely heavily on FitNesse, run many hours worth of FitNesse tests daily in our CI buildbot daily, and I personally wrote both FitNesse tests (using Fit wiki format in browser) and WebDriver tests in Python.
FitNesse is for end-to-end testing (browser automation) and Selenium/WebDriver in much superior replacement, especially if you already use Python.
FitNesse failed and I would NOT recommend anyone to start with FitNesse today.
You are much better off using Python and call Selenium WebDriver directly. Debugging test cases written in FitNesse pseudo-wiki format is nightmare. Idea was that end users (non-programmers) would write tests in wiki format. It was not to be. Programmers prefer real language and real editor, and can by order of magnitude more productive. Just say No.
Jenkins is much better test runner. And if your pages use Angular, you need more granular control of what is going on on the page.
Also, consider PageObject design pattern. Easy to use in any decent real programming language. Not so much in FitNesse: In FitNesse, you either use "copy-paste inheritance" or write your own fixtures for every page.
Trust me on this one. We did started with FitNesse a decade ago (when it was state-of-the-art in system-level testing) but now we struggle to get rid of it: we need to gradually replace all those FitNesse tests and refactor them to PageObject pattern. It was good decision decade ago, but today? No.
Also read: http://www.jamesshore.com/Blog/Five-Ways-to-Misuse-Fit.html

