Re: [rspec-users] webrat question, form without buttons
On Sep 3, 2008, at 1:51 PM, Nick Hoffman wrote: On 2008-09-03, at 13:38, Zach Dennis wrote: When the user clicks a button, but all of the handy dandy work is done in unobtrusive-style javascript. It's not a submit button. It's a CSS-made button with listeners attached, I'm afraid I can't be of much help with that. I've barely used Webrat. Sorry, mate! Sounds like this is out of RSpec / Story land. Maybe you guys should petition Brian to start a Webrat mailing list (or just start one yourself). Scott ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] story vs feature (was Documentation for Plain-Text Stories)
On Sat, Aug 30, 2008 at 2:31 PM, Scott Taylor [EMAIL PROTECTED] wrote: On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote: 2008-08-30 17:02, Matt Wynne: RuBehave Now _that's_ cool! I love it! Personally, I always liked the rbehave / rspec combo, of Mike Myers Ali G. Isn't Ali G one of those We ain't got no RSpec, all we got is the Rails console. guys G -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] specifying a controller's layout
I want to spec that a controller uses a particular layout how do I do that? cheers, Matt http://blog.mattwynne.net http://songkick.com In case you wondered: The opinions expressed in this email are my own and do not necessarily reflect the views of any former, current or future employers of mine. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] story vs feature (was Documentation for Plain-Text Stories)
On Thu, Sep 4, 2008 at 3:37 PM, Rick DeNatale [EMAIL PROTECTED] wrote: On Sat, Aug 30, 2008 at 2:31 PM, Scott Taylor [EMAIL PROTECTED] wrote: On Aug 30, 2008, at 2:12 PM, Tero Tilus wrote: 2008-08-30 17:02, Matt Wynne: RuBehave Now _that's_ cool! I love it! Personally, I always liked the rbehave / rspec combo, of Mike Myers Ali G. I lost the beginning of this thread... A crude migration guide is available here: http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories Aslak Isn't Ali G one of those We ain't got no RSpec, all we got is the Rails console. guys G -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] specifying a controller's layout
On Thu, Sep 4, 2008 at 8:42 AM, Matt Wynne [EMAIL PROTECTED] wrote: I want to spec that a controller uses a particular layout how do I do that? Depends on what else is going on, but this is the simplest situation: controller.expect_render(:layout = 'special_layout') get :some_action ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] specifying a controller's layout
noting my own typo def negeative_failure_message should be def negative_failure_message :) On Sep 4, 2008, at 10:24 AM, Matt Wynne wrote: Thanks David. I really struggled to get that to catch anything. My colleague Dan found this, which is working well for me: http://rubyforge.org/pipermail/rspec-users/2007-May/001816.html On 4 Sep 2008, at 15:05, David Chelimsky wrote: On Thu, Sep 4, 2008 at 8:42 AM, Matt Wynne [EMAIL PROTECTED] wrote: I want to spec that a controller uses a particular layout how do I do that? Depends on what else is going on, but this is the simplest situation: controller.expect_render(:layout = 'special_layout') get :some_action ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] specifying a controller's layout
On 4 Sep 2008, at 16:12, Jonathan Linowes wrote: noting my own typo def negeative_failure_message should be def negative_failure_message :) Copy Paste Considered Harmfull ;) Thanks ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] scenarios on production data
I'm just thinking out loud here... It could be useful to have a way to run scenarios on a copy of a fully populated production database, as an alternative to normal use. Not sure how that'd work, maybe replace the Given's but leave the Whens and Thens? linoj ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] Failing in TextMate but not in rake...
When I run a spec file from TextMate using the RSpec bundle's Run Examples command (either using command-R or the bundle menu item with the spec file open), I get an error dialog with the following text: Missing the Rails 2.0.2 gem. Please `gem install -v=2.0.2 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed. - Running 'rake spec SPEC=same spec file relative path' succeeds. - This line is in config./environment.rb: RAILS_GEM_VERSION = '2.0.2' unless defined? RAILS_GEM_VERSION - Running 'gem list rails' from the command line lists 'rails (2.0.2)' - I'm running on OS X Leopard with a version of Ruby installed from source into /usr/local, per Dan Benjamin's excellent instructions (http://hivelogic.com/articles/2008/02/ruby-rails-leopard). 'which ruby' finds '/usr/local/bin/ruby', 'which gem' finds '/usr/local/bin/gem'. - In TextMate's Advanced | Shell Variables, TM_RUBY is defined to '/usr/local/bin/ruby' (w/o the quotes). I'm guessing that TextMate is finding the wrong ruby or gem environment somehow, but I can't figure out how, or how to correct it. Any suggestions would be appreciated! Thanks in advance. Ed ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Four Question From an RSpec Baby - Give me something to chew
So, that was a great response to my questions. Thanks a lot, guys. Nick, Thanks for your help and your suggestions and your time. The articles you linked to were helpful, no doubt. Pat, I realize now that you're the guy I first heard about story runner from with your screencast on it. I think I saw that about a year ago and I'm just now getting into testing shame shame shame. Your insights are warmly welcomed and greatly appreciated. You are right when you say that it is never feasible to take weeks off to write code. Well, it has been one week now and I've taken your advice to start writing tests for code that I am changing or fixing. I promptly downloaded Cucumber and Webrat and set up an 'rspec' branch for my app in order to cherry pick commits with the master. All of a sudden, though, I didn't know anything about Cucumber, Webrat, or writing features. Not only that, I could only find scarce, miniature examples of Cucumber. No examples I found had much to do with a rails app, anyhow. So, I wrote one Feature and that worked out fine, I guess. I just haven't figured out how to re-use a Step, so that's tripping me up. Controller Specs are a different story... I've written three controller specs! Are they good controller specs, Lake? Well, maybe... I'm not quite sure. I guess the question turned from How do I become confident in my code? Write Specs! to How do I become confident in my Specs?! On the positive side, I feel like I am getting stronger with speccing. I've been using mocking and stubbing like I never have before. I think some things are becoming more natural, easier to grasp. I think the reason my brain wouldn't have it was because I was not USING IT, I just passively read about it... but I think I've hit that AHA moment with mocking and stubbing - or, at least, I'm steadily on my way to the climax of the moment. Thanks for your suggestions and help! I haven't read all of Chelimsky, or his friend's blogs, but I will. I did download the merb-core, though. :) Matt Wynne, Working Effective With Legacy Code is on the way. Thanks for taking time out of your day to help out. Hopefully, I'll be high fiving much more in the future. Oh, your latest article on your blog struck a note with me... also it led me to Michael Feathers blog, Thanks! Mark Wilden, First, your suggestion about mocking and stubbing really encouraged me to take up the task of learning about and using them. I feel like I actually experienced my AHA moment. I think you are right about testing units and keeping a unit, a unit. I'll certainly use Mocks and Stubs when I end up unit testing and then I'll fondly remember your post. Avdi Grimm, Thank you much for your added input. Especially about the book! Scott Taylor, Your post encouraged me to relax. The idea of chipping away really hit home with me especially since I have a... don't say it... a pickaxe! You are correct about not having enough time. I'll definitely generate the specdoc for the boss. Hopfully, I didn't leave anything important out... but now on to the mashed peas: Taking Pat's suggestion, I downloaded Cucumber - if you haven't used it, try it out. I haven't used story runner, so there! Anyways, I downloaded Cucumber and started writing a feature and the steps. Here is what I came up with: http://pastie.org/266264 That feature passes with flying covers. Am I in the right direction with it, though? Unfortunately, my feature fun ran out when I tried to re-use a step name in a different step file... Apparantly you can't duplicate steps? So, I moved on to a controller spec for a controller called admin/issues. Here is what I came up with... Don't cry, it's ugly: http://pastie.org/266272 That should be fairly readable, but I don't really know if I'm doing the right stuff. Any pointers would be very helpful. Those are the two files that I came up with in the last week. Well, I came up with a couple more, but those are the more completed ones. I'm really grateful that this stuff is falling in line, or at least I hope it is. Thanks for your time guys. Lake -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Four Question From an RSpec Baby - Give me something to chew
On 2008-08-27, at 15:25, Mark Wilden wrote: The other thing I would say is that mocking and stubbing are powerful tools that you should add to your arsenal as soon as possible. I've had several coworkers who resisted using them, only to finally achieve that aha! moment later. Your tests get easier to write, and they're less brittle to change. G'day Mark. I was re-reading this thread and noticed this paragraph of yours. I've been using RSpec and BDD for about 2 months now, and love it. However, I'm not a fan of mocking and stubbing, primarily for two reasons: 1) I believe that specs should test behaviour, rather than a behaviour's implementation. 2) Using mocks and stubs causes your specs and implementation to be tightly coupled, which often forces you to modify your specs if changes occur in the implementation. However, #2 contradicts what you said about tests ... [are] less brittle to change when using mocks and stubs. Considering that I'm still very new to mocks and stubs, I'm probably missing something here. When you have a minute, would you mind countering me? Thanks! Nick ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Four Question From an RSpec Baby - Give me something to chew
On Thu, Sep 4, 2008 at 7:14 PM, Nick Hoffman [EMAIL PROTECTED] wrote: On 2008-08-27, at 15:25, Mark Wilden wrote: The other thing I would say is that mocking and stubbing are powerful tools that you should add to your arsenal as soon as possible. I've had several coworkers who resisted using them, only to finally achieve that aha! moment later. Your tests get easier to write, and they're less brittle to change. G'day Mark. I was re-reading this thread and noticed this paragraph of yours. I've been using RSpec and BDD for about 2 months now, and love it. However, I'm not a fan of mocking and stubbing, primarily for two reasons: 1) I believe that specs should test behaviour, rather than a behaviour's implementation. This is a misleading statement. Testing the behavior of an object involves its input and output collaborators. When used appropriately mocks and stubs act as an agent for design and discovery. They also allow objects under test to be isolated from other objects that it depends on (which may not even exist yet). Collaborators are what should be used to set up with stubs and mock expectations. This way we can test the behavior of the object under test given different values returned by its collaborators. For example: class FundsTransfer def transfer(amount, source_account, target_account) if source_account.balance amount raise not enough money else source_account.deposit amount target_account.withdraw amount end end Without using mocks or stubs to test the above code I wouldn't be able to test the case where the source account doesn't have enough money or does have enough money -- unless I already have implemented the Account class and its withdraw, deposit and balance methods. Taking the approach of writing the Account class first is an approach that a lot of developers take. But you build what you think you need before you actually need it. I prefer to develop from the other direction, only building what I discover I need to make it work. Either way though behavior is being tested, and it is not testing against the internal state of an object. 2) Using mocks and stubs causes your specs and implementation to be tightly coupled, which often forces you to modify your specs if changes occur in the implementation. However, #2 contradicts what you said about tests ... [are] less brittle to change when using mocks and stubs. Considering that I'm still very new to mocks and stubs, I'm probably missing something here. When you have a minute, would you mind countering me? You can write bad tests with mocks/stubs and without mocks/stubs. Using mocks/stubs doesn't immediately tightly couple your specs to your implementation. It does however tie your specs to the external interface of the object under test. If you change that, then you will need update your specs. Consider our FundsTransfer example again: class FundsTransfer def transfer(amount, source_account, target_account) if source_account.balance amount raise not enough money else source_account.deposit amount target_account.withdraw amount end end If I supply a source_account that has a stubbed out balance of less than the amount requesting to be transferred am I tightly coupling the spec to the implementation? No more so then creating a source account fixture with an amount less than the amount that I am requesting to transfer. I say this because at some point you need to test the scenario where funds are requested to be transferred from a source account that doesn't have enough money. Do you really see one of the below examples more tightly coupling the test to the implementation? account = mock(Account, :balance = 0) account = Account.new :balance = 0 The difference to me is that using the mock allows me to discover earlier what interface I want to work with on the Account class. If I go the non-mock route then I need to make sure I build the Account class with the interfaces I need first. I much prefer to work in small steps. Focus on one behaviour, and then when it works as expected, make sure any collaborators that need to be implemented are. Then use my integration tests to make sure everything is wired up correctly together. That's just me though, -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Four Question From an RSpec Baby - Give me something to chew
Mark and Zach, you both posed great perspectives and gave great explanations. Thanks for taking the time to write all of that. I'm going to re-read your emails several times over the next couple of days and see how the info percolates into my brain. I may even rewrite my current specs using mocks and stubs to see how it feels. Much appreciated, guys! -Nick ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Four Question From an RSpec Baby - Give me something to chew
Nick Hoffman wrote: On 2008-08-27, at 15:25, Mark Wilden wrote: The other thing I would say is that mocking and stubbing are powerful tools that you should add to your arsenal as soon as possible. I've had several coworkers who resisted using them, only to finally achieve that aha! moment later. Your tests get easier to write, and they're less brittle to change. G'day Mark. I was re-reading this thread and noticed this paragraph of yours. I've been using RSpec and BDD for about 2 months now, and love it. However, I'm not a fan of mocking and stubbing, primarily for two reasons: 1) I believe that specs should test behaviour, rather than a behaviour's implementation. 2) Using mocks and stubs causes your specs and implementation to be tightly coupled, which often forces you to modify your specs if changes occur in the implementation. I'm completely with Zach on this subject, so I won't repeat what he has stated. I will however point out that many people who avoid using mocks simply based on the test the behaviour not the implementation argument fail to realize that the same argument applies just as much to state-based testing as it does to interaction-based testing (mocking.) Coupling a test to the implementation is much more subtle than using mocks to predefine collaborator interactions. Consider this glaringly stupid example in which an ambitious first-time BDDer writes the first spec for a Stack class: describe Stack do describe #push do it should add an item do stack = Stack.new stack.push(5) stack.items.should == [5] end end end To get this spec to pass they quickly churn out the following code, and all is green: class Stack attr_accessor :items def initialize @items = [] end def push(object) @items.push object end end The encapsulation of the Stack is clearly broken by adding the 'attr_accessor :items' call. Not just that, but the spec is now tied to how the stack implements it's behaviour. (In fact no relevant behaviour was even being speced in the first place, it was all internal structure!) If the Stack decides to use some other container or method to implement the behavior then all the specs would need to be changed. This was a painfully simple example, but the best I could come up with off the top of my head. I'm certainly not suggesting that using mocks here would be better, I'm just illustrating what I believe is meant by test the behaviour not the implementation. As programs grow in size these sort of issues tend to creep up more subtlety and such coupling isn't so obvious. I have noticed that with a purely state-based approach the creation and testing of objects at the unit level seems to increase in difficultly and require more setup as the complexity of a system increases. Mocks not only allow you to discover your interface but also help in breaking dependencies and keeping your unit level specs focused on just that object's responsibility. I should point out however that with every spec I have that uses mocking I always have an application level test (a story) that executes the same code with the full stack in motion. I'm also constantly trying to find a good balance between state and interaction based testing in my projects. I think that balance is different from project to project, team to team, and developer to developer. With all that said, I think mocking is a fantastic tool to have in your tool kit that can help alleviate a lot of the pain associated with testing and, as Zach explained, is a great tool to discover your design. Wow, sorry for the long-winded reply... that was not my intention when I began to write. :) As Mark pointed out a good article on the matter is Martin Fowler's: http://www.martinfowler.com/articles/mocksArentStubs.html If you read that article would recommend that you follow it up with this one to get another perspective: http://nat.truemesh.com/archives/000342.html -Ben http://www.benmabey.com ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
[rspec-users] is there a way to create spec tests (including directories) for an existing set of models/controllers?
Hi, is there a way to create spec tests (including directories) for an existing set of models/controllers? (i.e. as opposed to the generate options that rspec provides when you are creating models/controllers etc to start with) Tks ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
