Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)

share|improve this question

migrated from stackoverflow.com Apr 15 '11 at 3:11

This question came from our site for professional and enthusiast programmers.

    
Problem with "after-the-fact" unit tests is that you cannot be certain that the test actually tests anything. –  user1249 Apr 17 '11 at 17:55

3 Answers 3

up vote 3 down vote accepted

BDD scenarios generally have three purposes:

  • 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.