FitNesse

FitNesse is a self-hosted wiki for writing acceptance criteria and running them as tests. It suits software teams that want requirements and verification in one place and can operate a Java application. Its strongest case is keeping executable checks beside the documentation they validate.

Overview

FitNesse links stakeholder-written requirements to checks of expected application behavior, helping teams keep documentation aligned with software and catch regressions. Pages are edited in a browser using wiki syntax or a rich-text editor; anyone with web access to the server can run tests manually or automatically. That shared workflow is useful when business and delivery stakeholders need to refer to the same acceptance criteria, but it depends on a server the team installs and maintains.

The project began in 2001 as a wiki and HTML front end to FIT. It is distributed as a Java jar, stores wiki pages as files, and is released under the Common Public License version 1.0.

Key features

Executable acceptance criteria

FitNesse includes FIT and SLIM test systems, and tests can also run from JUnit or Maven. The Java core has extensions for other languages and environments, making it adaptable to varied test setups. That flexibility is valuable for teams with specific integration needs, though they must select and maintain the extensions and fixtures their application requires.

Integration and test coverage

Plugins cover Maven, Ivy, Gradle, Git, TFS, and SVN-related support. Fixtures include Selenium-based browser tests, REST API and HTTP checks, PDF checks, and email retrieval. This breadth can bring several kinds of acceptance checks into the same wiki, but FitNesse is not a turnkey test suite: teams still need to configure the relevant fixtures and application connections.

Security and operations

Reading, writing, and testing permissions can be controlled separately, but all three protections are disabled by default. Search and related queries do not require authentication, and unauthenticated readers can access files in the /files directory. Teams exposing the server should configure authentication and review those access paths rather than assume page restrictions cover the whole application. The security guidance recommends SSL for network traffic and password-cipher authentication; SSL for test-system-to-application communication is limited to the SLIM Java client.

Java 11 is required; Java 11, 17, and 21 are supported. Extensive use can exceed the JVM's default memory allocation, so memory-related test failures may require a larger heap. Those requirements make FitNesse a better fit for teams comfortable managing Java runtime and server configuration than for readers seeking a hosted, low-maintenance service.

Pricing

FitNesse — free. The free, open-source project has no commercial plans or stated usage limits. There is no free trial because the product is free. This suits teams that can self-host and configure it without a paid plan; the trade-off is operational responsibility, not a cheaper tier with fewer features.

Platforms

FitNesse supports API, Linux, macOS, self-hosted, web, and Windows. Its local execution mode and browser-based editing suit teams running the server in their own environment. Gherkin support, browser testing, and API access are also supported.

Who it's for

Choose FitNesse when a delivery team wants acceptance criteria to remain runnable and close to shared documentation, especially if it needs browser, API, or other fixture-based checks. It is less suitable for teams that cannot take responsibility for a Java deployment or need security protections enabled by default.

Pros and cons

• Pro: Requirements can double as executable checks, keeping expected behavior and regression verification together.
• Pro: Browser editing and manual or automatic test execution give stakeholders with server access a shared workflow.
• Pro: Built-in test systems and a broad set of integrations and fixtures support multiple testing workflows.
• Con: Read, write, and test protections are off by default, while some access paths remain unauthenticated.
• Con: Teams must deploy and maintain the Java application, configure its test integrations, and may need to increase JVM memory for extensive use.

Alternatives

Browse BDD Testing Tools to compare more options in the category.

• Serenity BDD is another free open-source option across Android, iOS, Linux, macOS, self-hosted, web, and Windows; its JUnit 4 support is deprecated and planned for removal in Serenity 6.0.0.
• Cucumber Open is a free open-source option for Android, API, Linux, macOS, and Windows; Cucumber Reports are free.
• Ginkgo is a free Go testing framework for Linux, macOS, and Windows, with v2 as its current supported major version.
• CukeTest offers a free Lite plan with visual feature editing, JavaScript and Python, and 500 automation API calls; some built-in automation libraries have usage limits.
• Karate has a free, MIT-licensed framework for REST, GraphQL, and SOAP API testing, browser and desktop UI automation, and Gatling performance testing.
• Reqnroll offers a Community plan with framework use, Visual Studio and Rider integration, community plugins, and community support; its Professional plan costs 40010.00 EUR per.
• Behat is free software for Linux, provided without warranty.
• Godog is MIT-licensed open-source software for API and self-hosted use; its API may change before version 1.0.0.

Verdict

FitNesse is a strong choice for teams that want acceptance criteria to serve as living, runnable documentation and are prepared to operate a Java server. Its free model and integrations are compelling, but teams should look elsewhere if they need default-on access controls or want to avoid deployment and security configuration.