fitnesse는 테스트 자동화 지원툴이다. 워드 커닝햄에게서 나왔다는 이 아이디어는 아주 참신한 것 같다.

1. 우선, HTML 테이블 형식으로 테스트 시나리오와 데이타를 기술한다. 기획자, 혹은 개발자, 혹은 테스터가.
2. 테이블 해더와 프로그램 함수를 매핑시키는 간단한 코드를 작성한다. 개발자가.
3. 그리고 나서, 툴을 돌리면 HTML 테이블을 참조해서 테스트가 실행되고 결과가 역시 테이블 형식으로 출력된다.

요는 test case 작성을 HTML 테이블로 하기때문에 작성이 쉽고, readable 하다는 것이다.

eg.Division
numerator	denominator	quotient?
10	2	5
12.6	3	4.2
100	4	33

이런 형식으로 input에 따른 output을 체크하게 작성할 수도 있고,

Action Fixture.
start	fitnesse.fixtures.CountFixture
check	counter	0
press	count
check	counter	1
press	count
check	counter	2
enter	counter	5
press	count
check	counter	6

이런 형식으로 일련의 input을 주면서 output을 체크할 수도 있다.
테이블 형식을 임의로 만들 수 있다는게 큰 장점이다. 물론 정해진 형식을 사용하지 않고 새로운 형식을 만들려면 테스트 코드 작성에 좀더 시간을 투자하긴 해야한다.

JUnit 같은 단위테스트 툴이 API 레벨의 테스팅에 적합하다면 fitnesse는 좀더 복잡한 테스트 시나리오를 기술하는데 적합해서 통합테스트나 기능 테스트에 적합하다고 한다.
테스트 시나리오를 직접 코딩하지 않고, HTML table로 작성하다고는 하지만, 직접 해보면 테스트 시나리오를 만드는 것 자체가 꽤 막연한 일이다. 어떤 데이타를 넣어봐야 하고, 어떤 순서로 테스트해야 하는지. 어느 수준에서 테스트를 해야 하는지 등이 그렇다. 당연히 개발자는 부담스러워 할 수 밖에 없고, 일단 대략적으로 테스트해가면서 코딩하고 나중에 테스터가 테스트하면서 버그를 찾아주길 선호할 것이다. 그래도 누군가 큰 맘을 먹고 상위레벨의 테스트 코드를 작성해 보기로 결심을 한다면 이 툴이 아주 큰 도움이 될것이다.

한가지 주의 사항: 모든 CASE tool 사용에 있어서 가장 큰 문제는 잘못된 사용방법이다. 테스트 시나리오가 모든 케이스들을 다 커버해야 한다는 강박관념은 버려야 할 것이고, 단위테스트가 아닌 기능테스트 용도로 사용이 되야 할 것이다.