Comments on: Outside-In BDD: How?! http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/ Mon, 26 Sep 2011 22:22:32 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Frank http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-616 Frank Tue, 23 Nov 2010 19:17:21 +0000 http://www.sarahmei.com/blog/?p=443#comment-616 I'm currently learning cucumber and I really appreciate your post! I really liked the part when you say: "Cucumber’s great for for happy path tests; I leave the rest to rspec.". It's a great advice I think. Until now I have always written some "unhappy path tests" in cucumber and they felt so unnatural... like they were not belonging there at all. I’m currently learning cucumber and I really appreciate your post! I really liked the part when you say: “Cucumber’s great for for happy path tests; I leave the rest to rspec.”. It’s a great advice I think. Until now I have always written some “unhappy path tests” in cucumber and they felt so unnatural… like they were not belonging there at all.

]]> By: Phil http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-428 Phil Sat, 09 Oct 2010 17:53:22 +0000 http://www.sarahmei.com/blog/?p=443#comment-428 Brilliant post. We are working hard on refocusing on complete BDD practices. And this is an excellent article! I know our learning curve is step, but this is going to help. Thanks! Brilliant post. We are working hard on refocusing on complete BDD practices. And this is an excellent article! I know our learning curve is step, but this is going to help.

Thanks!

]]> By: Pedro http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-318 Pedro Mon, 19 Jul 2010 22:48:35 +0000 http://www.sarahmei.com/blog/?p=443#comment-318 Great post! Regarding what to test, I find myself testing the controllers less frequently, as I'm using Jose Valim's inherited_resources's gem. I only test the actions I need to override. But other than that, very useful information. Great post! Regarding what to test, I find myself testing the controllers less frequently, as I’m using Jose Valim’s inherited_resources’s gem. I only test the actions I need to override. But other than that, very useful information.

]]> By: Dave Ott http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-297 Dave Ott Wed, 23 Jun 2010 22:05:49 +0000 http://www.sarahmei.com/blog/?p=443#comment-297 Great to see someone explain this process in a detailed manner. We've really started shying away from controller tests at Hashrocket on the whole. Mainly because if you need them then you're controller is doing too much (the controller in this post definitely doesn't do too much). We've adopted a method of exposing resources from a controller using a gem written by a colleague called decent_exposure. It eliminates the need for instance variables in controllers thereby tidying them up even further (ex: expose(:book) { Book.new(params[:book]) }). So a typical controller only has create, update, and destroy and those actions only handle their one responsibility and then redirect. So this one responsibility is really covered in the cucumber integration test. We've also been loving the excellent capybara gem lately for testing javascript operations in our integration tests. Makes me feel all warm and fuzzy to watch the cucumber suite run in selenium mode. Also agree with Anthony, should is redundant. When you're reading the english output from rspec #create: creates a book or redirects back to the book list is much nicer. These are picky things about an awesome post. Thanks for sharing this! Great to see someone explain this process in a detailed manner. We’ve really started shying away from controller tests at Hashrocket on the whole. Mainly because if you need them then you’re controller is doing too much (the controller in this post definitely doesn’t do too much). We’ve adopted a method of exposing resources from a controller using a gem written by a colleague called decent_exposure. It eliminates the need for instance variables in controllers thereby tidying them up even further (ex: expose(:book) { Book.new(params[:book]) }). So a typical controller only has create, update, and destroy and those actions only handle their one responsibility and then redirect. So this one responsibility is really covered in the cucumber integration test.

We’ve also been loving the excellent capybara gem lately for testing javascript operations in our integration tests. Makes me feel all warm and fuzzy to watch the cucumber suite run in selenium mode.

Also agree with Anthony, should is redundant. When you’re reading the english output from rspec #create: creates a book or redirects back to the book list is much nicer. These are picky things about an awesome post. Thanks for sharing this!

]]> By: Scott Burton http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-269 Scott Burton Mon, 07 Jun 2010 15:29:57 +0000 http://www.sarahmei.com/blog/?p=443#comment-269 @neeraj - if you're skipping view specs (I do), it can be tempting to skip controller specs too. In my view, though, it's helpful to cover every branch of conditionals, and ensure things like instance variables are named properly. You don't really want to leave that to Cucumber. @neeraj – if you’re skipping view specs (I do), it can be tempting to skip controller specs too. In my view, though, it’s helpful to cover every branch of conditionals, and ensure things like instance variables are named properly. You don’t really want to leave that to Cucumber.

]]> By: Andree Wille http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-267 Andree Wille Sun, 06 Jun 2010 07:15:55 +0000 http://www.sarahmei.com/blog/?p=443#comment-267 Great post! A lot more people should follow this workflow. It would then also be easier to maintain legacy code. I agree with Anthony try to get rid of the shoulds in cucumber tests. Great post! A lot more people should follow this workflow. It would then also be easier to maintain legacy code. I agree with Anthony try to get rid of the shoulds in cucumber tests.

]]> By: Desmond http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-266 Desmond Sun, 06 Jun 2010 02:29:19 +0000 http://www.sarahmei.com/blog/?p=443#comment-266 Thanks for the great post! I remember watching a Cucumber presentation a while ago with a similar walk-through (sorry, I can't seem to find the link), but I like having it written down so I can refer to it easily. You've convinced me to actually try Cucumber out on my next project. :) Thanks for the great post! I remember watching a Cucumber presentation a while ago with a similar walk-through (sorry, I can’t seem to find the link), but I like having it written down so I can refer to it easily. You’ve convinced me to actually try Cucumber out on my next project. :)

]]> By: Aslak Hellesøy http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-265 Aslak Hellesøy Sun, 06 Jun 2010 02:09:14 +0000 http://www.sarahmei.com/blog/?p=443#comment-265 Sarah, you get Outside-In and you get Cucumber. Great post! Sarah, you get Outside-In and you get Cucumber. Great post!

]]> By: Ryan Dick http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-262 Ryan Dick Fri, 04 Jun 2010 06:15:54 +0000 http://www.sarahmei.com/blog/?p=443#comment-262 Excellent post Sarah. This addresses the fundamental issue underlying the question I posed to the SF Ruby Meetup group a few weeks back, and has further crystallized my understanding of the Outside-In development process. I know you mentioned this in the caveat in the beginning, but a great follow-up post would be explaining the Outside-In approach when your models become more complex and include functions that should be tested. Great work! Excellent post Sarah. This addresses the fundamental issue underlying the question I posed to the SF Ruby Meetup group a few weeks back, and has further crystallized my understanding of the Outside-In development process.

I know you mentioned this in the caveat in the beginning, but a great follow-up post would be explaining the Outside-In approach when your models become more complex and include functions that should be tested.

Great work!

]]> By: Neeraj Singh http://www.sarahmei.com/blog/2010/05/29/outside-in-bdd/comment-page-1/#comment-257 Neeraj Singh Tue, 01 Jun 2010 08:49:50 +0000 http://www.sarahmei.com/blog/?p=443#comment-257 Do we really need to write controller tests while writing cucumber tests. As I am writing more and cucumber tests I am noticing that I am writing less and less controller tests. If controller has some complex functionality then I move the feature to lib to keep controller really really skinny. And then I write test for all the stuff inside lib. Again am I missing something by not writing controller tests? Do we really need to write controller tests while writing cucumber tests.

As I am writing more and cucumber tests I am noticing that I am writing less and less controller tests. If controller has some complex functionality then I move the feature to lib to keep controller really really skinny. And then I write test for all the stuff inside lib.

Again am I missing something by not writing controller tests?

]]>