Subscribe
Contact Us
SearchCheck out Behaviors for Ruby
Posted on January 14th, 2007 by
Shawn Crowley and Karlin Fox
If you are looking to add a hint of BDD spice to your ruby TestCases, check out our recently updated Behaviors gem.
gem install behaviors
- Atomic Object
- Blog
- Atomic Object
- Pages
- Sections
-
Archive
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- July 2006
- June 2006
- December 2005
- November 2005
- October 2005
- January 2005
- December 2004
Dustin Says:
January 14th, 2007 at 01:24 PMI feel like with behaviors you lose 2, related, and very important aspects of testing. 1st is the ability to scan your test file and see all the functionality of method X. 2nd is when a test fails the ability to know right away what method it was that the test relates to.
Shawn Crowley Says:
January 15th, 2007 at 05:37 AMDustin, I have noticed having the same feeling when testing rails controllers that start to get large. Outside of rails, I don't notice the same trouble due to the ease of refactoring classes into smaller components with specific roles. You can still use naming conventions to help map a should method from behaviors to the method you are testing. Naming the object under test @target can help you see the method call being tested in a block of test code. This technique doesn't really help with functional tests in rails though. You may get some mileage out of RSpec contexts for grouping tests related to a particular action. I heard that you have checked out test/spec, which has contexts too. I'd be interested to hear about what other tools you are using and more specific details about how they are helping your work.
Bill Bereza Says:
January 15th, 2007 at 06:47 AMI think it also helps if you've broken down your code enough so that that name of methods corresponds to the behaviour. Meaning, that each method in a class should be there to implement one and only one behaviour. Therefore, the name of the test and the method can be the same, or close.
Karlin Fox Says:
January 15th, 2007 at 09:58 AMI often use behaviors for system tests where behavioral description is more important and applicable than method names. Using should's in unit tests can work for some jobs, but it occludes meaning for others.
Dustin Says:
January 15th, 2007 at 10:11 AMBill, I agree with breaking down the code, however with rails on your controller you will almost always have the CRUD operations that will have similar behaviors. As far as I've seen there isn't really a way to get around a controller, such as users, having a show, update, delete, and index action. For all of these actions their behaviors will be very similar and confusing if not given a context. Examples: test_show_should_404_if_user_is_not_logged_in test_index_should_redirect_if_user_is_not_logged_in