# FitNesse: a Java acceptance test wiki that ships as one server and two jars

> FitNesse is a Java acceptance test framework and wiki where the suites are wiki pages served from the same tree as the product code. Most of the friction sits in the build and in packaging, and the distance between the newest commit and the newest published build is the first number to check.

**unclebob/fitnesse** — FitNesse -- The Acceptance Test Wiki

- Repository: https://github.com/unclebob/fitnesse
- Website: fitnesse.org
- Stars: 2,149 · Forks: 705
- Language: Java
- License: NOASSERTION
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/unclebob-fitnesse

## A Java server that carries the wiki in the tree

FitNesse ships as one Java program that does two jobs: it serves a wiki and it runs acceptance suites out of that wiki. The split shows up in the build. `./gradlew test` runs the unit tests, `./gradlew acceptanceTest` runs a different set, and `./gradlew run` starts the wiki itself, which the IntelliJ walkthrough says you then open at http://localhost:8001 in a browser. Three commands, and only one of them needs a browser.

The repository layout suits teams that keep acceptance material next to the code it covers. Wiki content sits in FitNesseRoot/ at the top level beside src/ and test/, and build.gradle, settings.gradle and buildSrc/ sit alongside it. Configuration is kept in plain properties files rather than in a database: plugins.properties says what to load, plugins/ holds them, and configuration-parameter-test.properties exercises that configuration from the suite side.

The people it fits are domain experts who will not learn a test language, plus developers who want a suite a browser can open at a URL. What that arrangement costs shows up in the build steps, in the packaging, and in the gap between the newest commit and the newest published build.

## Two download channels point at different artifacts

The Quick start sends you to the website for the download and for plugins, and a few lines later the edge build notes point at GitHub Actions for what is called the latest stable build. Two channels in one page, and they do not hand you the same file.

The Actions route is spelled out more precisely. Click the latest workflow, click the `libs` artifact, and the note states that the artifact contains 2 jars. One of them, `fitnesse.jar`, is for Maven or Ivy. The other one is the file you want if you only intend to run FitNesse by yourself, and the instruction names it directly: use `fitnesse-standalone.jar` instead of `fitnesse.jar`. Take the artifact by name alone and you have picked up the jar meant for a build tool.

The site route is thinner. The Quick start links to https://fitnesse.org/FitNesseDownload.html for the download and to https://fitnesse.org/PlugIns.html for plugins, with no file name, version or checksum printed next to either link. Nothing in the tree records which build a given downloaded zip came from, so a team that wants to trace a running wiki back to its origin has to write that down itself.

## Four Gradle tasks and a wiki on port 8001

From a clone, four documented Gradle tasks cover most of the work. The build bootstraps itself: the repository states that a proper internet connection is sufficient, because the build downloads Gradle and then the dependencies required to build and test FitNesse. Building everything, tests included, is the default invocation and it builds the `all` target:

```bash
$ ./gradlew
```

Starting the wiki is a separate task, and the local User Guide is the stated reason to run it:

```bash
$ ./gradlew run
```

After that, open http://localhost:8001 and the wiki answers in the browser. On Windows the same wrapper is spelled differently: call `gradlew.bat` instead of `./gradlew`.

Tests come in two flavours, each with its own target:

```bash
$ ./gradlew test
$ ./gradlew acceptanceTest
```

That is the whole first run. No configuration file has to be created, no service has to be registered, and the port named in the IDE walkthrough is 8001. For anyone who would rather not build from source, the downloadable build at the website is the shortcut, and the jar naming rule above still applies to it.

## A plain compile skips the steps the acceptance tests need

Compiling is not the main thing `./gradlew` does, and this is where IDE users lose time. The build does extra work apart from compiling the code: it sets the FitNesse version in META-INF/FitNesseVersion.txt, and it copies the dependencies into the lib folder so the acceptance tests can use them. That copy has its own task, because an IDE compile never triggers it on its own:

```bash
$ ./gradlew copyRuntimeLibs
```

The suggested fix is a post-compilation step bound to the target from the build file, and the README says that with the post-compile target set you avoid trouble when cleaning, building and executing tests from the IDE.

Two IDE paths are spelled out in detail. In Eclipse you import the cloned folder as a Gradle Project and make sure the project properties use a Java 11 compiler or newer. In IntelliJ IDEA 2025.1 you create the project from version control, set the project structure to a Java 11 SDK or newer, open the Gradle pane, and start the wiki from Tasks/other with the cog icon, which is where http://localhost:8001 comes from. A third path needs nothing but VSCode and Docker: open the folder, wait for the message about a Dev Container configuration file, press `Reopen in Container`, and use the Run & Debug or Gradle buttons.

## Settings live in properties files and a plugin folder

FitNesse's own configuration surface is small and file based, which is convenient until you want to know what loaded. plugins.properties at the top level names the plugins to load, plugins/ holds them, and plugin-loader-test/ exists to exercise that loading path. Suite settings follow the same pattern: configuration-parameter-test.properties sits beside the other top-level entries, so suite parameters are properties rather than code.

The supporting entries show what the build itself is made of. build.gradle and settings.gradle sit at the root, buildSrc/ holds custom build logic, parserTokens.txt is a data file kept next to the parser sources, and extra/ is a place for additions. sonar-project.properties and .bettercodehub.yml keep quality tooling configured in the tree, and SECURITY.md gives vulnerability reports a file to live in.

None of that is written out in prose in the repository. The Quick start routes every usage question to the User Guide on fitnesse.org, so the syntax a new author needs lives on a site that moves independently of this tree. Learn the page format from the site guide and the build behaviour from the task list, because the two live in different places.

## The newest tag is older than the newest commit

Commit history and published builds have drifted apart here. The last push on master was on 2026-04-20, while the newest published tag is v20251025 dated 2025-10-25, and the two older tags, 20241207 and 20241026, both fall in December 2024. Roughly six months of work in the tree has no named build, so anyone pinning v20251025 is not running what master holds.

Two other things matter before a team commits. The licence is a custom one that GitHub cannot classify, the tree ships both LICENSE.txt and licenseHeader.txt, and the cut itself is made with tooling kept at https://github.com/fitnesse/fitnesse-release rather than from this tree.

Upgrade cost, then, is not a version bump. The build stamps whatever version the Gradle logic computes into META-INF/FitNesseVersion.txt, so a locally built jar carries a version string you cannot match against a published list, because that list stops at 2025-10-25. Teams that pin a build for repeatable results have to record the commit hash themselves.

## Standalone server or build tool: two ways in

Two consumption paths are described, and they differ in more than file names. Running the program yourself means starting a server, opening http://localhost:8001 and working in a browser: suites are edited as pages and triggered by a person, and the wiki is the whole interface. Putting `fitnesse.jar` on a Maven or Ivy classpath means the framework sits inside a build tool instead, and the same suites are triggered from the build lifecycle with no browser in the path.

That is the actual alternative, and the difference is about who runs the tests rather than about what gets asserted. The standalone path needs `fitnesse-standalone.jar`, a running process and a human at a keyboard. The embedded path needs a dependency declaration and whatever your build tool already provides.

The repository documents the artifact split but gives no Maven or Ivy snippet, no coordinates beyond the badge link, and no command line for running one page. Check that before designing a pipeline around it, because a pipeline is where the two paths diverge most and where this documentation is thinnest.

## Where the wiki server is the wrong tool

Several situations make it the wrong tool. A machine with no route to the internet cannot follow the documented build, since the wrapper downloads Gradle and then the dependencies, and no offline path is described. An IDE without the post-compile binding compiles cleanly and then fails acceptance tests for libraries missing from the lib folder.

It is also the wrong shape when the acceptance material is not page shaped. Anyone who wants a suite beside the Java unit tests in one reviewable diff has to edit pages in FitNesseRoot/ by hand, because nothing in the build turns a Java test into a page or a page back into a test. Reviewers who want failure output next to the assertion in one file will not find it.

What the repository does not say matters as much. There is no rollback procedure, no compatibility list across builds, and no migration note for content you have already written. All three gaps sit in the upgrade path, and all three surface on the day you try to move from v20251025 to the code at master.

## Conclusion

Adopt it when acceptance tests must be written and read as wiki pages by people who never touch the build, and accept that a browser sits in the loop. Leave it when suites must live in the same reviewable diff as the feature they cover, or when an offline build matters. Verify first that `./gradlew run` reaches http://localhost:8001 on your Java 11 setup, that `./gradlew copyRuntimeLibs` runs before any IDE test run, and that the published tag list stopping at 2025-10-25 leaves you building from master yourself.

## FAQ

### How do I start a local FitNesse wiki after cloning the repository?

Run `./gradlew run` and the wiki answers at http://localhost:8001 in your browser. On Windows the wrapper is spelled `gradlew.bat` instead of `./gradlew`.

### Which jar from the libs artifact should I use to run FitNesse myself?

`fitnesse.jar` is the one for Maven or Ivy. To run the program on its own, use `fitnesse-standalone.jar` instead of `fitnesse.jar`.

### What Java version does FitNesse need when I build it from an IDE?

The Eclipse import steps ask for a Java 11 compiler or newer, and the IntelliJ IDEA 2025.1 steps ask for a Java 11 SDK or newer.

### Why do acceptance tests fail in my IDE right after a fresh clone?

The Gradle build copies dependencies into the lib folder for the acceptance tests, and a plain IDE compile does not run that copy. Run `./gradlew copyRuntimeLibs`, or set the post-compile target from the build file as an IDE post-compilation step.

### Can I run a single FitNesse suite without starting the wiki server?

No such command is written down in this repository. The entry points described are the Gradle tasks and a wiki served at http://localhost:8001, so a shell run of one page has to be worked out from the site guide.

## Sources

- [Issues](https://github.com/unclebob/fitnesse/issues)
- [README](https://github.com/unclebob/fitnesse/blob/master/README.md)
- [Releases](https://github.com/unclebob/fitnesse/releases)
- [unclebob/fitnesse on GitHub](https://github.com/unclebob/fitnesse)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unclebob-fitnesse