FitNesse Test History with Version Control

3
votes

I'm starting some automated acceptance testing for our company, and have decided to use FitNesse.

I want to have FitNesse under source control - that is the FitNesse executable + plugins, the wiki pages and the test fixture source code.

Then anyone can get all they need from source control to build and run the acceptance tests locally. Including a Continuous Integration server.

I have read that the page versioning can be turned off using the -e 0 parameters. Then we don't have ZIP files in the FitNesse root folder under source control - nice.

But what about Test History? Do I want the history of locally ran tests to be checked in? And when someone gets the latest version, do they want their local test history to be overwritten?

I'm very grateful to anyone who can share their experiences of using FitNesse in similar scenarios to that described above.

2
version-controlautomated-testsfitnesse

2 Answers

1
votes

Why do you not clear all test history before check-in?

In my current project, there are only 2 required operations for creating test cases on FitNesse: Drawing the table(Edit the page) and developing the api(output as .dll files).

We also develop a tool for triggering the FitNesse running testing from remote machines automatically. After finish testing, we get the testing result by handling the output excel files.

The structure of our svn:

-SVN
 --FitNess
  --- TestLib
  --- FitNesse
     ---- FitNesseBin
     ---- TestCases

[Update]

Test Fixture code should be finished and frozen before testers start writing test cases and running them. Certainly, when Test Fixture need bug fixing or enhancement, the code could also be changed. In my team, we ask different roles to handle different tasks. Developer provide API for testing use. Senior QA wrap the API in test fixture. QA write the table/wiki. Every role only take the assigned parts. Before modification, team member should update local copy of the FixNesse, and check-out the file. And only check-in the modified check-outed file.

0
votes

Disabling and auto-purging of test history is still a valid requirement for those integrating fitnesse into a standard build (e.g. Maven) and for running fitnesse builds locally, despite .svnignore .gitignore etc options.

The test history slows down the finalisation of the test and when it's purged after a few runs you will certainly notice the difference.

Uncle Bob mentioned he was working on an option to only keep the test history for the latest test run (you always need at least 1 so you can show the results) here http://tech.groups.yahoo.com/group/fitnesse/message/14306 but cannot see such an option in the code. I got a python error trying to reply to post - so no answer on that option unfortunately :-(