Created
September 12, 2010 17:28
-
-
Save barinek/576262 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| A benefit of test driving Rails applications, especially underlying | |
| model behaviors, is the documentation that results from test driving. | |
| When I want to quickly ramp up on a new Gem, I always look at the | |
| test suite for insight into how the Gem or subsystem works. | |
| I've been diving into (http://cukes.info/, "Cucumber") recently | |
| and have been a long time user of (http://fitnesse.org/ "FitNesse"), | |
| although with Cucumber I've recently watched developers opt to not | |
| write unit tests and replace their test suite entirely with Cucumber features. | |
| Even with FitNesse I was still driving my test suite from individual | |
| units and using FitNesse for true acceptance or classic black-box tests. | |
| The question quickly becomes, how do Cucumber tests help better | |
| document developer intentions? | |
| In addition, how do I extract common, re-useable modules into Gems | |
| or Concernes from an application and include them within another | |
| and maintaining confidence in my test suite. Do I attempt to pull | |
| the associate Features as well? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment