Comments on: 2 techniques for rails testing without fixtures http://scoop.simplyexcited.co.uk/2007/11/13/2-techniques-for-rails-testing-without-fixtures/ Technology, Design and Outdoor Fri, 16 Dec 2011 10:35:12 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: pyrat http://scoop.simplyexcited.co.uk/2007/11/13/2-techniques-for-rails-testing-without-fixtures/comment-page-1/#comment-728 pyrat Wed, 14 Nov 2007 10:11:46 +0000 http://scoop.cheerfactory.co.uk/2007/11/13/2-techniques-for-rails-testing-without-fixtures/#comment-728 Thanks for the comment SP. I hope to use Rspec for the next project that I work on. I went to the Rspec tutorial at railsconf europe and was intrigued. I'll let you know how it goes. Thanks for the comment SP.

I hope to use Rspec for the next project that I work on. I went to the Rspec tutorial at railsconf europe and was intrigued.

I’ll let you know how it goes.

]]> By: SP http://scoop.simplyexcited.co.uk/2007/11/13/2-techniques-for-rails-testing-without-fixtures/comment-page-1/#comment-727 SP Tue, 13 Nov 2007 23:08:24 +0000 http://scoop.cheerfactory.co.uk/2007/11/13/2-techniques-for-rails-testing-without-fixtures/#comment-727 Good to see people that have recently converted to TDD are starting to realize the errors of the fixture ways. However, what you are doing here is just creating fixtures in Ruby code (rather than the YAML fixtures). I have noticed far superior "testing" can be achieved by using RSpec and adopting the BDD ways instead of regression-heavy TDD way. I see a big difference between the two (TDD and BDD). Many old hat extreme prgrammers (XPers) find the BDD way unintuitive, but I find the BDD a more comprehensive way to "specify" your software. The mindset shift you need to make coming from regression-heavy TDD mindset is that you need to start thinking about testing software contracts instead of asserting output data values assuming certain input data. If you start a new Rails (or any Ruby) project, I would strong suggest you use RSpec instead of Test::Unit and take full advantage of the builtin mocking and stubbing, so fixtures (even ones created in Ruby code) will be a thing of the past. If you find the RSpec way a little too much you can also utilize mocha to mocking objects decently. The only major benefit you miss by going half assed with Test::Unit+mocha is that you don't have the syntactic sugar, which surprisingly provides clarity while thinking about your software specifications. Good to see people that have recently converted to TDD are starting to realize the errors of the fixture ways. However, what you are doing here is just creating fixtures in Ruby code (rather than the YAML fixtures). I have noticed far superior “testing” can be achieved by using RSpec and adopting the BDD ways instead of regression-heavy TDD way. I see a big difference between the two (TDD and BDD).

Many old hat extreme prgrammers (XPers) find the BDD way unintuitive, but I find the BDD a more comprehensive way to “specify” your software. The mindset shift you need to make coming from regression-heavy TDD mindset is that you need to start thinking about testing software contracts instead of asserting output data values assuming certain input data.

If you start a new Rails (or any Ruby) project, I would strong suggest you use RSpec instead of Test::Unit and take full advantage of the builtin mocking and stubbing, so fixtures (even ones created in Ruby code) will be a thing of the past.

If you find the RSpec way a little too much you can also utilize mocha to mocking objects decently. The only major benefit you miss by going half assed with Test::Unit+mocha is that you don’t have the syntactic sugar, which surprisingly provides clarity while thinking about your software specifications.

]]>