If a project was coded without much (or any) formal documentation and is without unit tests, does it make any sense to use tools like Fitnesse and SpecFlow to write automated acceptance tests as the documentation, the specs, for the code?

To use unit tests as the means of being specs would come at too high a cost. I'm all for adding them as new functionality comes or bugs get fixed, but not for retroactively "spec-ing" and testing a system. Could such an approach with Fitnesse, SpecFlow, or other tools work with what amounts to the BDD approach in reverse? Or would it be a BAD idea (pun semi-seriously intended: B ehavior A fter D evelopment)

3 Answers
3

Having conversations about scenarios lets everyone discuss the behavior of the system and explore any misunderstandings or gaps in knowledge. This is a great thing to do anyway, since you'll gain a better understanding of how the system works and uncover assumptions about how it ought to work compared to how it actually does.

Capturing conversations about scenarios acts as documentation for the system.

Automating scenarios acts as a regression test for the system and helps reduce the manual testing burden.

If all you want to do is document the scenarios, you may be better off using a Wiki.

However, if you actually want to produce regression scenarios - for instance, because you're trying to bring a legacy system into a maintainable state and will be doing lots of refactoring - then automation is an excellent idea.

You may find that you want to automate some of the scenarios, capturing the areas which you're refactoring, and document the knowledge you discover elsewhere.

I'm not sure what those tools are, but I would suggest getting a rough set of requirements, ie. "What is this program supposed to do?" Once you have that, write tests for all the requirements.

I wouldn't write tests based on the existing code, because the existing code may be incorrect.

You don't need to write nearly so many tests as development, because you don't need to test every function in the code. Instead, you are testing whether the system as a whole is doing what it's supposed to. And I feel this would certainly be worthwhile.

It is generally considered good practice to write the specs before development, but sometimes it doesn't happen that way.

One of the nice features of SpecFlow is that it can handle unimplemented tests well. You can write a complete set of specs at a high level and they will all return inconclusive rather than pass/fail. Initially the tests are documentation only, but as you work on specific parts of the code you can implement the steps and end up with a full set of automated tests.

Deciding how you will organize the tests is fairly important. SpecFlow works well for unit tests as well as acceptance tests, but the two generally don't fit nicely into the same document structure.