From brian.takita at gmail.com Tue Apr 1 03:43:21 2008 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 1 Apr 2008 00:43:21 -0700 Subject: [rspec-devel] BaseFormatter.example_started(example) suspicious behavior In-Reply-To: <001a01c88464$51755860$6bf01aac@Labs.IntelliJ.Net> References: <001a01c88464$51755860$6bf01aac@Labs.IntelliJ.Net> Message-ID: <1d7ddd110804010043t53d2dda7o9334cbb281c8d99f@mail.gmail.com> Hello Roman, Nice to see you in the rspec forum. It looks like you are creating and running an ExampleGroup within an Example. The "Special Example Group" is run and outputs before its container Example is output. I don't think I follow what that issue is about. Thanks, Brian On Wed, Mar 12, 2008 at 10:12 AM, Roman Chernyatchik wrote: > Hi guys! > > I'm developing a custom formatter for RSpec(Rake Runner Plugin for TeamCity > buildserver, see draft description at > http://www.jetbrains.net/confluence/display/RUBYDEV/TeamCity+Rake+Runner). > > I've noticed some problems during running tests. > > 1. On RSpec project, rev.3331. > 'Spec::Runner::Formatter::BaseFormatter.start' and > 'Spec::Runner::Formatter::BaseFormatter.dump_summary' methods returns > different example counts. > I.e. > 'Spec::Runner::Formatter::BaseFormatter.start' - 1255 > 'Spec::Runner::Formatter::BaseFormatter.dump' - 1314 > > 2. In some cases RSpec starts example in one group and ends in other example > group. > > How to reproduce: > Let's consider RSpec spec tests. You can see such behavior in html output or > by simple debug print: > > E.g. in rspec/spec/spec/example/configuration_spec.rb example group > > ########################### > describe "#prepend_before" do > it "prepends the before block on all instances of the passed in > type" do > order = [] > > ... > > @example_group.it "calls prepend_before" do > end > > @example_group.run > order.should == [ > ... > ] > end > end > ########################### > > leads to HTML output: > > --------------------------- > Spec::Example::Configuration#prepend_before > > Special Example Group > calls prepend_before > prepends the before block on all instances of the passed in type > --------------------------- > In fact the order of events is: > > 1. BaseFormatter.add_example_group : example group description = > "Spec::Example::Configuration#prepend_before" > 2. BaseFormatter.example_started : example description = "prepends the > before block on all instances of the passed in type" > > 3. BaseFormatter.add_example_group : example group description = "Special > Example Group" > 4. BaseFormatter.example_started : example description = "prepend_before" > 5. BaseFormatter.example_passed : example description = "calls > prepend_before" > 6. BaseFormatter.example_passed : example description = "prepends the > before block on all instances of the passed in type" > > 7. BaseFormatter.add_example_group : example group description = > "Spec::Example::Configuration#append_before" > .... > ----------------------------- > This problem can be reproduced on 1.1.3 and trunk versions. > > > > ---- > Chernyatchik Roman > JetBrains, Inc > http://www.jetbrains.com > "Develop with pleasure!" > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From zach.dennis at gmail.com Tue Apr 1 17:29:01 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 1 Apr 2008 17:29:01 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... Message-ID: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> I've got model helpers which perform reflection on associations to ensure a relationship exists as expected. It doesn't test the association (I think Rails does a pretty good job of ensuring the association works). I'm looking for feedback on if folks (and the rspec team =) would accept such a patch. Example: describe SomeModel do it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" it_has_one :fuzzbucket it_belongs_to :another_model end it relies on the top level describe's description_type to determine what model to reflect on. It removes a lot of boilerplate code for spec'ing standard associations. Thoughts? -- Zach Dennis http://www.continuousthinking.com From dchelimsky at gmail.com Tue Apr 1 18:09:48 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 1 Apr 2008 18:09:48 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> Message-ID: <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> On Tue, Apr 1, 2008 at 5:29 PM, Zach Dennis wrote: > I've got model helpers which perform reflection on associations to > ensure a relationship exists as expected. It doesn't test the > association (I think Rails does a pretty good job of ensuring the > association works). I'm looking for feedback on if folks (and the > rspec team =) would accept such a patch. I'd rather see you publish this on its own. When we include things like this in rspec proper, they become harder for us to change later. > > Example: > > describe SomeModel do > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > it_has_one :fuzzbucket > it_belongs_to :another_model > end I see more and more structures appearing like this. I have very mixed feelings about them. This is about structure, not behaviour. Even if the underlying code is actually approaching this in a more behavioural way, it's still expressing structure at the high level. Also, if the widget's fuzzbucket moves to inside a fuzzbucketcontainer, this all has to change. Whereas if the presence of 0, 1 or many fuzzbuckets has some impact on behaviour, then examples that express that impact will not have to change as the internal widget structure changes. Other thoughts? > it relies on the top level describe's description_type to determine > what model to reflect on. It removes a lot of boilerplate code for > spec'ing standard associations. > > Thoughts? > > -- > Zach Dennis > http://www.continuousthinking.com > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From pergesu at gmail.com Tue Apr 1 18:38:54 2008 From: pergesu at gmail.com (Pat Maddox) Date: Tue, 1 Apr 2008 15:38:54 -0700 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> Message-ID: <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky wrote: > > Example: > > > > describe SomeModel do > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > > it_has_one :fuzzbucket > > it_belongs_to :another_model > > end > > I see more and more structures appearing like this. I have very mixed > feelings about them. This is about structure, not behaviour. Even if > the underlying code is actually approaching this in a more behavioural > way, it's still expressing structure at the high level. I don't have mixed feelings about this. I think this type of spec is terrible. It completely duplicates the implementation. It's not even testing anything. This is not a value judgment against you though, Zach. I think when people do stuff like this they genuinely have good intentions. It's just that it seems to be quite difficult to test highly declarative stuff like AR associations. Now that I've given my rather harsh opinion, I have to get back to work :) I'll try follow up later with something more helpful like thoughts on how to write better specs. Pat From adam at thewilliams.ws Tue Apr 1 19:06:14 2008 From: adam at thewilliams.ws (Adam Williams) Date: Tue, 1 Apr 2008 19:06:14 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> Message-ID: <59463972-B8F0-4BF4-B85C-50894A639A53@thewilliams.ws> On Apr 1, 2008, at 6:38 PM, Pat Maddox wrote: > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky > wrote: >>> Example: >>> >>> describe SomeModel do >>> it_has_many :widgets, :destroy => :null, :class_name => >>> "BaseWidget" >>> it_has_one :fuzzbucket >>> it_belongs_to :another_model >>> end >> >> I see more and more structures appearing like this. I have very mixed >> feelings about them. This is about structure, not behaviour. Even if >> the underlying code is actually approaching this in a more >> behavioural >> way, it's still expressing structure at the high level. > > I don't have mixed feelings about this. I think this type of spec is > terrible. It completely duplicates the implementation. It's not even > testing anything. > > This is not a value judgment against you though, Zach. I think when > people do stuff like this they genuinely have good intentions. It's > just that it seems to be quite difficult to test highly declarative > stuff like AR associations. I lean this way myself, and find that the best way to test associations is by writing integration tests which prove that when an administrator clicks delete on a user account, the user and his stuff should be gone. I'd love to hear your thoughts on style, Pat. aiwilliams From zach.dennis at gmail.com Tue Apr 1 19:20:08 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Tue, 1 Apr 2008 19:20:08 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> Message-ID: <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox wrote: > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky wrote: > > > Example: > > > > > > describe SomeModel do > > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > > > it_has_one :fuzzbucket > > > it_belongs_to :another_model > > > end > > > > I see more and more structures appearing like this. I have very mixed > > feelings about them. This is about structure, not behaviour. Even if > > the underlying code is actually approaching this in a more behavioural > > way, it's still expressing structure at the high level. > > I don't have mixed feelings about this. I think this type of spec is > terrible. It completely duplicates the implementation. It's not even > testing anything. > > This is not a value judgment against you though, Zach. I think when > people do stuff like this they genuinely have good intentions. It's > just that it seems to be quite difficult to test highly declarative > stuff like AR associations. > > Now that I've given my rather harsh opinion, I have to get back to > work :) I'll try follow up later with something more helpful like > thoughts on how to write better specs. > I don't like the fact that it tests the structure of the association (as opposed to testing the behavior), but I do like that it tests the conceptual relationship between models. I find value in this. Even though it is declarative it is very clear and meaningful to the next guy looking at the code, and if someone changes something incidentally they are quickly pointed to the fact that they broke a conceptual relationship between two models. Please do respond with more thoughts, as this is a topic I'd like to get hammered out as it will provide value to every developer on this list, -- Zach Dennis http://www.continuousthinking.com From pergesu at gmail.com Wed Apr 2 20:11:52 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 2 Apr 2008 17:11:52 -0700 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> Message-ID: <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> On Tue, Apr 1, 2008 at 4:20 PM, Zach Dennis wrote: > > On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox wrote: > > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky wrote: > > > > Example: > > > > > > > > describe SomeModel do > > > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > > > > it_has_one :fuzzbucket > > > > it_belongs_to :another_model > > > > end > > > > > > I see more and more structures appearing like this. I have very mixed > > > feelings about them. This is about structure, not behaviour. Even if > > > the underlying code is actually approaching this in a more behavioural > > > way, it's still expressing structure at the high level. > > > > I don't have mixed feelings about this. I think this type of spec is > > terrible. It completely duplicates the implementation. It's not even > > testing anything. > > > > This is not a value judgment against you though, Zach. I think when > > people do stuff like this they genuinely have good intentions. It's > > just that it seems to be quite difficult to test highly declarative > > stuff like AR associations. > > > > Now that I've given my rather harsh opinion, I have to get back to > > work :) I'll try follow up later with something more helpful like > > thoughts on how to write better specs. > > > > I don't like the fact that it tests the structure of the association > (as opposed to testing the behavior), but I do like that it tests the > conceptual relationship between models. I find value in this. Even > though it is declarative it is very clear and meaningful to the next > guy looking at the code, and if someone changes something incidentally > they are quickly pointed to the fact that they broke a conceptual > relationship between two models. > > Please do respond with more thoughts, as this is a topic I'd like to > get hammered out as it will provide value to every developer on this > list, I've put some more thought into this and have a bit of time to reply. So here goes. The first thing I'm going to do is demonstrate why I feel this is a bad spec. Please understand that this is not a criticism of anyone in particular. I'm merely using this as an example of specs that don't add any value. Take a look at the spec again: describe SomeModel do it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" it_has_one :fuzzbucket it_belongs_to :another_model end Change 'describe' to 'class' and remove 'do' from the first line. Then remove the 'it_' from the next three lines. At this point you have the exact implementation of the class. I don't know about you, but that bothers the hell out of me. The concrete benefits of object-level specification are, in my mind, that it - helps you design your code well - leaves behind regression tests - provides executable examples of how to use code Often when we write specs we have to balance those goals...for example, one major criticism of using mocks is that tests that use mocks don't act as effective regression tests. That's a valid criticism in certain contexts, but you'll find that most people who make such criticisms are being myopic - they either don't understand or don't share the other goals, and so write the technique off all together. Besides the fact that the given association helpers duplicate the implementation to an i-t-underscore, what else is wrong with them? I would argue that they provide 0 value in all three categories. They don't help drive the design. You either need widgets or you don't. If you decide you do, you add a declaration to the implementation. Done. There was never any question about how to design it. Rails made that decision for you. They have no value as regression tests. How likely is it that any of that code will break? Not likely at all. It's not like anyone's ever going to go in there and change the behavior, because there is no behavior, other than that which is abstracted away by Rails (thus already thoroughly tested). If you make any change to the implementation then the specs will fail...so they're brittle without providing any value. The lack of documentation value should be obvious. The specs don't show you how to use the objects together. You have to know how Rails associations work. And you get absolutely no information from the spec that you don't get from the implementation itself. Hopefully that clarifies why I don't feel that specs like these are valuable. I also hope that this helps others develop heuristics for when to write/delete/ignore tests. With that out of the way, how would I specify this SomeModel class? Well, if the class is as given and there's no business logic, then I would only write a couple specs for SomeModel directly. These would be specs for the widgets association. describe SomeModel, "widgets" do before(:each) do @model = SomeModel.create! BaseWidget.create! :some_model_id => @model.id end it "should find BaseWidgets" do @model.should have(1).widget end it "should nullify keys when deleting the widgets" do lambda { @model.widgets.destroy_all }.should_not change(BaseWidget, :count) @model.should have(0).widgets end end The reason I would do this is because there's a greater chance that some of this stuff could break. None of the other associations will. Looking back at this, I'm not sure that I would write the second example. The reason I might not write it is that I don't think I have enough information. The foreign keys get nulled out when I call #destroy_all, but that's something that I know from the has_many declaration, and that I know works. My real question at this point is WHY I want the keys nulled out instead of just deleting the records. Do I have some requirement in the system that these associations should be broken, but the child records should stick around? If so, I should have another spec that demonstrates that behavior. These associations *should* be tested, but they should be tested indirectly from _somewhere else_. They're not important enough to deserve tests at such a low granularity. They should be tested via an acceptance test where a view iterates through them, or some test which calls a DB aggregate method on the proxy. They don't have any interesting behavior on their own, and we are concerned primarily with behavior. Does that help? Pat From zach.dennis at gmail.com Wed Apr 2 22:40:25 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Wed, 2 Apr 2008 22:40:25 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> Message-ID: <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> Pat, That was a wonderfully thought out reply and at first read your reasoning makes a lot of sense. Thank you for taking the time to write it. I am going to let it sink in over the next few days, Zach On Wed, Apr 2, 2008 at 8:11 PM, Pat Maddox wrote: > > On Tue, Apr 1, 2008 at 4:20 PM, Zach Dennis wrote: > > > > On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox wrote: > > > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky wrote: > > > > > Example: > > > > > > > > > > describe SomeModel do > > > > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > > > > > it_has_one :fuzzbucket > > > > > it_belongs_to :another_model > > > > > end > > > > > > > > I see more and more structures appearing like this. I have very mixed > > > > feelings about them. This is about structure, not behaviour. Even if > > > > the underlying code is actually approaching this in a more behavioural > > > > way, it's still expressing structure at the high level. > > > > > > I don't have mixed feelings about this. I think this type of spec is > > > terrible. It completely duplicates the implementation. It's not even > > > testing anything. > > > > > > This is not a value judgment against you though, Zach. I think when > > > people do stuff like this they genuinely have good intentions. It's > > > just that it seems to be quite difficult to test highly declarative > > > stuff like AR associations. > > > > > > Now that I've given my rather harsh opinion, I have to get back to > > > work :) I'll try follow up later with something more helpful like > > > thoughts on how to write better specs. > > > > > > > I don't like the fact that it tests the structure of the association > > (as opposed to testing the behavior), but I do like that it tests the > > conceptual relationship between models. I find value in this. Even > > though it is declarative it is very clear and meaningful to the next > > guy looking at the code, and if someone changes something incidentally > > they are quickly pointed to the fact that they broke a conceptual > > relationship between two models. > > > > Please do respond with more thoughts, as this is a topic I'd like to > > get hammered out as it will provide value to every developer on this > > list, > > I've put some more thought into this and have a bit of time to reply. > So here goes. > > The first thing I'm going to do is demonstrate why I feel this is a > bad spec. Please understand that this is not a criticism of anyone in > particular. I'm merely using this as an example of specs that don't > add any value. > > Take a look at the spec again: > > > describe SomeModel do > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > it_has_one :fuzzbucket > it_belongs_to :another_model > end > > Change 'describe' to 'class' and remove 'do' from the first line. > Then remove the 'it_' from the next three lines. At this point you > have the exact implementation of the class. > > I don't know about you, but that bothers the hell out of me. > > The concrete benefits of object-level specification are, in my mind, that it > - helps you design your code well > - leaves behind regression tests > - provides executable examples of how to use code > > Often when we write specs we have to balance those goals...for > example, one major criticism of using mocks is that tests that use > mocks don't act as effective regression tests. That's a valid > criticism in certain contexts, but you'll find that most people who > make such criticisms are being myopic - they either don't understand > or don't share the other goals, and so write the technique off all > together. > > Besides the fact that the given association helpers duplicate the > implementation to an i-t-underscore, what else is wrong with them? I > would argue that they provide 0 value in all three categories. > > They don't help drive the design. You either need widgets or you > don't. If you decide you do, you add a declaration to the > implementation. Done. There was never any question about how to > design it. Rails made that decision for you. > > They have no value as regression tests. How likely is it that any of > that code will break? Not likely at all. It's not like anyone's ever > going to go in there and change the behavior, because there is no > behavior, other than that which is abstracted away by Rails (thus > already thoroughly tested). If you make any change to the > implementation then the specs will fail...so they're brittle without > providing any value. > > The lack of documentation value should be obvious. The specs don't > show you how to use the objects together. You have to know how Rails > associations work. And you get absolutely no information from the > spec that you don't get from the implementation itself. > > Hopefully that clarifies why I don't feel that specs like these are > valuable. I also hope that this helps others develop heuristics for > when to write/delete/ignore tests. > > With that out of the way, how would I specify this SomeModel class? > Well, if the class is as given and there's no business logic, then I > would only write a couple specs for SomeModel directly. These would > be specs for the widgets association. > > describe SomeModel, "widgets" do > before(:each) do > @model = SomeModel.create! > BaseWidget.create! :some_model_id => @model.id > end > > it "should find BaseWidgets" do > @model.should have(1).widget > end > > it "should nullify keys when deleting the widgets" do > lambda { @model.widgets.destroy_all }.should_not change(BaseWidget, :count) > @model.should have(0).widgets > end > end > > The reason I would do this is because there's a greater chance that > some of this stuff could break. None of the other associations will. > > Looking back at this, I'm not sure that I would write the second > example. The reason I might not write it is that I don't think I have > enough information. The foreign keys get nulled out when I call > #destroy_all, but that's something that I know from the has_many > declaration, and that I know works. My real question at this point is > WHY I want the keys nulled out instead of just deleting the records. > Do I have some requirement in the system that these associations > should be broken, but the child records should stick around? If so, I > should have another spec that demonstrates that behavior. > > These associations *should* be tested, but they should be tested > indirectly from _somewhere else_. They're not important enough to > deserve tests at such a low granularity. They should be tested via an > acceptance test where a view iterates through them, or some test which > calls a DB aggregate method on the proxy. They don't have any > interesting behavior on their own, and we are concerned primarily with > behavior. > > Does that help? > > Pat > -- Zach Dennis http://www.continuousthinking.com From adam at thewilliams.ws Wed Apr 2 22:45:49 2008 From: adam at thewilliams.ws (Adam Williams) Date: Wed, 2 Apr 2008 22:45:49 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> Message-ID: On Apr 2, 2008, at 8:11 PM, Pat Maddox wrote: > Does that help? Yes, Pat. This is well said. Thanks for the time. A bit more work may make this a great blog post. aiwilliams From dchelimsky at gmail.com Wed Apr 2 22:50:52 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 2 Apr 2008 22:50:52 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> Message-ID: <57c63afe0804021950j3daf517fx8692ba820b1e6651@mail.gmail.com> On Wed, Apr 2, 2008 at 10:40 PM, Zach Dennis wrote: > Pat, > > That was a wonderfully thought out reply and at first read your > reasoning makes a lot of sense. +1 > Thank you for taking the time to write > it. +1 more Cheers, David > I am going to let it sink in over the next few days, > > Zach > > > > > On Wed, Apr 2, 2008 at 8:11 PM, Pat Maddox wrote: > > > > On Tue, Apr 1, 2008 at 4:20 PM, Zach Dennis wrote: > > > > > > On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox wrote: > > > > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky wrote: > > > > > > Example: > > > > > > > > > > > > describe SomeModel do > > > > > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > > > > > > it_has_one :fuzzbucket > > > > > > it_belongs_to :another_model > > > > > > end > > > > > > > > > > I see more and more structures appearing like this. I have very mixed > > > > > feelings about them. This is about structure, not behaviour. Even if > > > > > the underlying code is actually approaching this in a more behavioural > > > > > way, it's still expressing structure at the high level. > > > > > > > > I don't have mixed feelings about this. I think this type of spec is > > > > terrible. It completely duplicates the implementation. It's not even > > > > testing anything. > > > > > > > > This is not a value judgment against you though, Zach. I think when > > > > people do stuff like this they genuinely have good intentions. It's > > > > just that it seems to be quite difficult to test highly declarative > > > > stuff like AR associations. > > > > > > > > Now that I've given my rather harsh opinion, I have to get back to > > > > work :) I'll try follow up later with something more helpful like > > > > thoughts on how to write better specs. > > > > > > > > > > I don't like the fact that it tests the structure of the association > > > (as opposed to testing the behavior), but I do like that it tests the > > > conceptual relationship between models. I find value in this. Even > > > though it is declarative it is very clear and meaningful to the next > > > guy looking at the code, and if someone changes something incidentally > > > they are quickly pointed to the fact that they broke a conceptual > > > relationship between two models. > > > > > > Please do respond with more thoughts, as this is a topic I'd like to > > > get hammered out as it will provide value to every developer on this > > > list, > > > > I've put some more thought into this and have a bit of time to reply. > > So here goes. > > > > The first thing I'm going to do is demonstrate why I feel this is a > > bad spec. Please understand that this is not a criticism of anyone in > > particular. I'm merely using this as an example of specs that don't > > add any value. > > > > Take a look at the spec again: > > > > > > describe SomeModel do > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" > > it_has_one :fuzzbucket > > it_belongs_to :another_model > > end > > > > Change 'describe' to 'class' and remove 'do' from the first line. > > Then remove the 'it_' from the next three lines. At this point you > > have the exact implementation of the class. > > > > I don't know about you, but that bothers the hell out of me. > > > > The concrete benefits of object-level specification are, in my mind, that it > > - helps you design your code well > > - leaves behind regression tests > > - provides executable examples of how to use code > > > > Often when we write specs we have to balance those goals...for > > example, one major criticism of using mocks is that tests that use > > mocks don't act as effective regression tests. That's a valid > > criticism in certain contexts, but you'll find that most people who > > make such criticisms are being myopic - they either don't understand > > or don't share the other goals, and so write the technique off all > > together. > > > > Besides the fact that the given association helpers duplicate the > > implementation to an i-t-underscore, what else is wrong with them? I > > would argue that they provide 0 value in all three categories. > > > > They don't help drive the design. You either need widgets or you > > don't. If you decide you do, you add a declaration to the > > implementation. Done. There was never any question about how to > > design it. Rails made that decision for you. > > > > They have no value as regression tests. How likely is it that any of > > that code will break? Not likely at all. It's not like anyone's ever > > going to go in there and change the behavior, because there is no > > behavior, other than that which is abstracted away by Rails (thus > > already thoroughly tested). If you make any change to the > > implementation then the specs will fail...so they're brittle without > > providing any value. > > > > The lack of documentation value should be obvious. The specs don't > > show you how to use the objects together. You have to know how Rails > > associations work. And you get absolutely no information from the > > spec that you don't get from the implementation itself. > > > > Hopefully that clarifies why I don't feel that specs like these are > > valuable. I also hope that this helps others develop heuristics for > > when to write/delete/ignore tests. > > > > With that out of the way, how would I specify this SomeModel class? > > Well, if the class is as given and there's no business logic, then I > > would only write a couple specs for SomeModel directly. These would > > be specs for the widgets association. > > > > describe SomeModel, "widgets" do > > before(:each) do > > @model = SomeModel.create! > > BaseWidget.create! :some_model_id => @model.id > > end > > > > it "should find BaseWidgets" do > > @model.should have(1).widget > > end > > > > it "should nullify keys when deleting the widgets" do > > lambda { @model.widgets.destroy_all }.should_not change(BaseWidget, :count) > > @model.should have(0).widgets > > end > > end > > > > The reason I would do this is because there's a greater chance that > > some of this stuff could break. None of the other associations will. > > > > Looking back at this, I'm not sure that I would write the second > > example. The reason I might not write it is that I don't think I have > > enough information. The foreign keys get nulled out when I call > > #destroy_all, but that's something that I know from the has_many > > declaration, and that I know works. My real question at this point is > > WHY I want the keys nulled out instead of just deleting the records. > > Do I have some requirement in the system that these associations > > should be broken, but the child records should stick around? If so, I > > should have another spec that demonstrates that behavior. > > > > These associations *should* be tested, but they should be tested > > indirectly from _somewhere else_. They're not important enough to > > deserve tests at such a low granularity. They should be tested via an > > acceptance test where a view iterates through them, or some test which > > calls a DB aggregate method on the proxy. They don't have any > > interesting behavior on their own, and we are concerned primarily with > > behavior. > > > > Does that help? > > > > Pat > > > > > > > -- > Zach Dennis > http://www.continuousthinking.com > _______________________________________________ > > > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From tmhaines at gmail.com Wed Apr 2 23:01:40 2008 From: tmhaines at gmail.com (Tim Haines) Date: Thu, 3 Apr 2008 16:01:40 +1300 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <57c63afe0804021950j3daf517fx8692ba820b1e6651@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> <57c63afe0804021950j3daf517fx8692ba820b1e6651@mail.gmail.com> Message-ID: I totally agree. This sort of comment/guidance/opinion should be findable from (or included on) the rspec.info page on models.. Pat - thanks a bunch for taking the time! Tim. On 03/04/2008, David Chelimsky wrote: > > On Wed, Apr 2, 2008 at 10:40 PM, Zach Dennis > wrote: > > Pat, > > > > That was a wonderfully thought out reply and at first read your > > reasoning makes a lot of sense. > > > +1 > > > > Thank you for taking the time to write > > it. > > > +1 more > > Cheers, > > David > > > > I am going to let it sink in over the next few days, > > > > Zach > > > > > > > > > > On Wed, Apr 2, 2008 at 8:11 PM, Pat Maddox wrote: > > > > > > On Tue, Apr 1, 2008 at 4:20 PM, Zach Dennis > wrote: > > > > > > > > On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox > wrote: > > > > > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky < > dchelimsky at gmail.com> wrote: > > > > > > > Example: > > > > > > > > > > > > > > describe SomeModel do > > > > > > > it_has_many :widgets, :destroy => :null, :class_name => > "BaseWidget" > > > > > > > it_has_one :fuzzbucket > > > > > > > it_belongs_to :another_model > > > > > > > end > > > > > > > > > > > > I see more and more structures appearing like this. I have > very mixed > > > > > > feelings about them. This is about structure, not > behaviour. Even if > > > > > > the underlying code is actually approaching this in a more > behavioural > > > > > > way, it's still expressing structure at the high level. > > > > > > > > > > I don't have mixed feelings about this. I think this type of > spec is > > > > > terrible. It completely duplicates the implementation. It's > not even > > > > > testing anything. > > > > > > > > > > This is not a value judgment against you though, Zach. I > think when > > > > > people do stuff like this they genuinely have good > intentions. It's > > > > > just that it seems to be quite difficult to test highly > declarative > > > > > stuff like AR associations. > > > > > > > > > > Now that I've given my rather harsh opinion, I have to get > back to > > > > > work :) I'll try follow up later with something more helpful > like > > > > > thoughts on how to write better specs. > > > > > > > > > > > > > I don't like the fact that it tests the structure of the > association > > > > (as opposed to testing the behavior), but I do like that it tests > the > > > > conceptual relationship between models. I find value in this. > Even > > > > though it is declarative it is very clear and meaningful to the > next > > > > guy looking at the code, and if someone changes something > incidentally > > > > they are quickly pointed to the fact that they broke a conceptual > > > > relationship between two models. > > > > > > > > Please do respond with more thoughts, as this is a topic I'd like > to > > > > get hammered out as it will provide value to every developer on > this > > > > list, > > > > > > I've put some more thought into this and have a bit of time to > reply. > > > So here goes. > > > > > > The first thing I'm going to do is demonstrate why I feel this is a > > > bad spec. Please understand that this is not a criticism of anyone > in > > > particular. I'm merely using this as an example of specs that don't > > > add any value. > > > > > > Take a look at the spec again: > > > > > > > > > describe SomeModel do > > > it_has_many :widgets, :destroy => :null, :class_name => > "BaseWidget" > > > it_has_one :fuzzbucket > > > it_belongs_to :another_model > > > end > > > > > > Change 'describe' to 'class' and remove 'do' from the first line. > > > Then remove the 'it_' from the next three lines. At this point you > > > have the exact implementation of the class. > > > > > > I don't know about you, but that bothers the hell out of me. > > > > > > The concrete benefits of object-level specification are, in my mind, > that it > > > - helps you design your code well > > > - leaves behind regression tests > > > - provides executable examples of how to use code > > > > > > Often when we write specs we have to balance those goals...for > > > example, one major criticism of using mocks is that tests that use > > > mocks don't act as effective regression tests. That's a valid > > > criticism in certain contexts, but you'll find that most people who > > > make such criticisms are being myopic - they either don't understand > > > or don't share the other goals, and so write the technique off all > > > together. > > > > > > Besides the fact that the given association helpers duplicate the > > > implementation to an i-t-underscore, what else is wrong with > them? I > > > would argue that they provide 0 value in all three categories. > > > > > > They don't help drive the design. You either need widgets or you > > > don't. If you decide you do, you add a declaration to the > > > implementation. Done. There was never any question about how to > > > design it. Rails made that decision for you. > > > > > > They have no value as regression tests. How likely is it that any > of > > > that code will break? Not likely at all. It's not like anyone's > ever > > > going to go in there and change the behavior, because there is no > > > behavior, other than that which is abstracted away by Rails (thus > > > already thoroughly tested). If you make any change to the > > > implementation then the specs will fail...so they're brittle without > > > providing any value. > > > > > > The lack of documentation value should be obvious. The specs don't > > > show you how to use the objects together. You have to know how > Rails > > > associations work. And you get absolutely no information from the > > > spec that you don't get from the implementation itself. > > > > > > Hopefully that clarifies why I don't feel that specs like these are > > > valuable. I also hope that this helps others develop heuristics for > > > when to write/delete/ignore tests. > > > > > > With that out of the way, how would I specify this SomeModel class? > > > Well, if the class is as given and there's no business logic, then I > > > would only write a couple specs for SomeModel directly. These would > > > be specs for the widgets association. > > > > > > describe SomeModel, "widgets" do > > > before(:each) do > > > @model = SomeModel.create! > > > BaseWidget.create! :some_model_id => @model.id > > > end > > > > > > it "should find BaseWidgets" do > > > @model.should have(1).widget > > > end > > > > > > it "should nullify keys when deleting the widgets" do > > > lambda { @model.widgets.destroy_all }.should_not > change(BaseWidget, :count) > > > @model.should have(0).widgets > > > end > > > end > > > > > > The reason I would do this is because there's a greater chance that > > > some of this stuff could break. None of the other associations > will. > > > > > > Looking back at this, I'm not sure that I would write the second > > > example. The reason I might not write it is that I don't think I > have > > > enough information. The foreign keys get nulled out when I call > > > #destroy_all, but that's something that I know from the has_many > > > declaration, and that I know works. My real question at this point > is > > > WHY I want the keys nulled out instead of just deleting the records. > > > Do I have some requirement in the system that these associations > > > should be broken, but the child records should stick around? If so, > I > > > should have another spec that demonstrates that behavior. > > > > > > These associations *should* be tested, but they should be tested > > > indirectly from _somewhere else_. They're not important enough to > > > deserve tests at such a low granularity. They should be tested via > an > > > acceptance test where a view iterates through them, or some test > which > > > calls a DB aggregate method on the proxy. They don't have any > > > interesting behavior on their own, and we are concerned primarily > with > > > behavior. > > > > > > Does that help? > > > > > > Pat > > > > > > > > > > > > > -- > > Zach Dennis > > http://www.continuousthinking.com > > _______________________________________________ > > > > > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080403/4e695e25/attachment-0001.html From ben at benmabey.com Wed Apr 2 23:11:35 2008 From: ben at benmabey.com (Ben Mabey) Date: Wed, 02 Apr 2008 21:11:35 -0600 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> Message-ID: <47F44AE7.6070808@benmabey.com> Thanks Pat, that is a very good argument and I totally agree with it. When I began down the BDD path I found myself wanting/adding specs like the ones that we are talking about. I'm realizing now that a better way to approach associations is like you suggested write some spec that tests the actual behaviour of those associations. You will then see red until the correct association is set up and they are exercised. -Ben Zach Dennis wrote: > Pat, > > That was a wonderfully thought out reply and at first read your > reasoning makes a lot of sense. Thank you for taking the time to write > it. I am going to let it sink in over the next few days, > > Zach > > > On Wed, Apr 2, 2008 at 8:11 PM, Pat Maddox wrote: > >> On Tue, Apr 1, 2008 at 4:20 PM, Zach Dennis wrote: >> > >> > On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox wrote: >> > > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky wrote: >> > > > > Example: >> > > > > >> > > > > describe SomeModel do >> > > > > it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" >> > > > > it_has_one :fuzzbucket >> > > > > it_belongs_to :another_model >> > > > > end >> > > > >> > > > I see more and more structures appearing like this. I have very mixed >> > > > feelings about them. This is about structure, not behaviour. Even if >> > > > the underlying code is actually approaching this in a more behavioural >> > > > way, it's still expressing structure at the high level. >> > > >> > > I don't have mixed feelings about this. I think this type of spec is >> > > terrible. It completely duplicates the implementation. It's not even >> > > testing anything. >> > > >> > > This is not a value judgment against you though, Zach. I think when >> > > people do stuff like this they genuinely have good intentions. It's >> > > just that it seems to be quite difficult to test highly declarative >> > > stuff like AR associations. >> > > >> > > Now that I've given my rather harsh opinion, I have to get back to >> > > work :) I'll try follow up later with something more helpful like >> > > thoughts on how to write better specs. >> > > >> > >> > I don't like the fact that it tests the structure of the association >> > (as opposed to testing the behavior), but I do like that it tests the >> > conceptual relationship between models. I find value in this. Even >> > though it is declarative it is very clear and meaningful to the next >> > guy looking at the code, and if someone changes something incidentally >> > they are quickly pointed to the fact that they broke a conceptual >> > relationship between two models. >> > >> > Please do respond with more thoughts, as this is a topic I'd like to >> > get hammered out as it will provide value to every developer on this >> > list, >> >> I've put some more thought into this and have a bit of time to reply. >> So here goes. >> >> The first thing I'm going to do is demonstrate why I feel this is a >> bad spec. Please understand that this is not a criticism of anyone in >> particular. I'm merely using this as an example of specs that don't >> add any value. >> >> Take a look at the spec again: >> >> >> describe SomeModel do >> it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" >> it_has_one :fuzzbucket >> it_belongs_to :another_model >> end >> >> Change 'describe' to 'class' and remove 'do' from the first line. >> Then remove the 'it_' from the next three lines. At this point you >> have the exact implementation of the class. >> >> I don't know about you, but that bothers the hell out of me. >> >> The concrete benefits of object-level specification are, in my mind, that it >> - helps you design your code well >> - leaves behind regression tests >> - provides executable examples of how to use code >> >> Often when we write specs we have to balance those goals...for >> example, one major criticism of using mocks is that tests that use >> mocks don't act as effective regression tests. That's a valid >> criticism in certain contexts, but you'll find that most people who >> make such criticisms are being myopic - they either don't understand >> or don't share the other goals, and so write the technique off all >> together. >> >> Besides the fact that the given association helpers duplicate the >> implementation to an i-t-underscore, what else is wrong with them? I >> would argue that they provide 0 value in all three categories. >> >> They don't help drive the design. You either need widgets or you >> don't. If you decide you do, you add a declaration to the >> implementation. Done. There was never any question about how to >> design it. Rails made that decision for you. >> >> They have no value as regression tests. How likely is it that any of >> that code will break? Not likely at all. It's not like anyone's ever >> going to go in there and change the behavior, because there is no >> behavior, other than that which is abstracted away by Rails (thus >> already thoroughly tested). If you make any change to the >> implementation then the specs will fail...so they're brittle without >> providing any value. >> >> The lack of documentation value should be obvious. The specs don't >> show you how to use the objects together. You have to know how Rails >> associations work. And you get absolutely no information from the >> spec that you don't get from the implementation itself. >> >> Hopefully that clarifies why I don't feel that specs like these are >> valuable. I also hope that this helps others develop heuristics for >> when to write/delete/ignore tests. >> >> With that out of the way, how would I specify this SomeModel class? >> Well, if the class is as given and there's no business logic, then I >> would only write a couple specs for SomeModel directly. These would >> be specs for the widgets association. >> >> describe SomeModel, "widgets" do >> before(:each) do >> @model = SomeModel.create! >> BaseWidget.create! :some_model_id => @model.id >> end >> >> it "should find BaseWidgets" do >> @model.should have(1).widget >> end >> >> it "should nullify keys when deleting the widgets" do >> lambda { @model.widgets.destroy_all }.should_not change(BaseWidget, :count) >> @model.should have(0).widgets >> end >> end >> >> The reason I would do this is because there's a greater chance that >> some of this stuff could break. None of the other associations will. >> >> Looking back at this, I'm not sure that I would write the second >> example. The reason I might not write it is that I don't think I have >> enough information. The foreign keys get nulled out when I call >> #destroy_all, but that's something that I know from the has_many >> declaration, and that I know works. My real question at this point is >> WHY I want the keys nulled out instead of just deleting the records. >> Do I have some requirement in the system that these associations >> should be broken, but the child records should stick around? If so, I >> should have another spec that demonstrates that behavior. >> >> These associations *should* be tested, but they should be tested >> indirectly from _somewhere else_. They're not important enough to >> deserve tests at such a low granularity. They should be tested via an >> acceptance test where a view iterates through them, or some test which >> calls a DB aggregate method on the proxy. They don't have any >> interesting behavior on their own, and we are concerned primarily with >> behavior. >> >> Does that help? >> >> Pat >> >> > > > > From loop at superinfinite.com Thu Apr 3 03:45:12 2008 From: loop at superinfinite.com (Bart Zonneveld) Date: Thu, 3 Apr 2008 09:45:12 +0200 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> <85d99afe0804021940n363749barc2e639340292ca0c@mail.gmail.com> <57c63afe0804021950j3daf517fx8692ba820b1e6651@mail.gmail.com> Message-ID: On 3-apr-2008, at 5:01, Tim Haines wrote: > I totally agree. This sort of comment/guidance/opinion should be > findable from (or included on) the rspec.info page on models.. +1 I was thinking along the same lines as Pat when I first was speccing my models with behaviours. However, I still use specs like: it "should have many comments" Post.should have_many(:comments).depending end and be done with it. See http://stevetooke.karmatrading.co.uk/2007/8/10/simple-rails- association-matching-with-rspec I like the way I can write the spec now. It should have many comments. Red. has_many :comments, :dependent => :destroy. Green. Commit. Be done with it :). cheers, bartz > Pat - thanks a bunch for taking the time! > > Tim. > > On 03/04/2008, David Chelimsky wrote: On > Wed, Apr 2, 2008 at 10:40 PM, Zach Dennis > wrote: > > Pat, > > > > That was a wonderfully thought out reply and at first read your > > reasoning makes a lot of sense. > > > +1 > > > > Thank you for taking the time to write > > it. > > > +1 more > > Cheers, > > David > > > > I am going to let it sink in over the next few days, > > > > Zach > > > > > > > > > > On Wed, Apr 2, 2008 at 8:11 PM, Pat Maddox > wrote: > > > > > > On Tue, Apr 1, 2008 at 4:20 PM, Zach Dennis > wrote: > > > > > > > > On Tue, Apr 1, 2008 at 6:38 PM, Pat Maddox > wrote: > > > > > On Tue, Apr 1, 2008 at 3:09 PM, David Chelimsky > wrote: > > > > > > > Example: > > > > > > > > > > > > > > describe SomeModel do > > > > > > > it_has_many :widgets, :destroy > => :null, :class_name => "BaseWidget" > > > > > > > it_has_one :fuzzbucket > > > > > > > it_belongs_to :another_model > > > > > > > end > > > > > > > > > > > > I see more and more structures appearing like this. > I have very mixed > > > > > > feelings about them. This is about structure, not > behaviour. Even if > > > > > > the underlying code is actually approaching this in > a more behavioural > > > > > > way, it's still expressing structure at the high level. > > > > > > > > > > I don't have mixed feelings about this. I think this > type of spec is > > > > > terrible. It completely duplicates the > implementation. It's not even > > > > > testing anything. > > > > > > > > > > This is not a value judgment against you though, Zach. > I think when > > > > > people do stuff like this they genuinely have good > intentions. It's > > > > > just that it seems to be quite difficult to test highly > declarative > > > > > stuff like AR associations. > > > > > > > > > > Now that I've given my rather harsh opinion, I have to > get back to > > > > > work :) I'll try follow up later with something more > helpful like > > > > > thoughts on how to write better specs. > > > > > > > > > > > > > I don't like the fact that it tests the structure of the > association > > > > (as opposed to testing the behavior), but I do like that > it tests the > > > > conceptual relationship between models. I find value in > this. Even > > > > though it is declarative it is very clear and meaningful > to the next > > > > guy looking at the code, and if someone changes something > incidentally > > > > they are quickly pointed to the fact that they broke a > conceptual > > > > relationship between two models. > > > > > > > > Please do respond with more thoughts, as this is a topic > I'd like to > > > > get hammered out as it will provide value to every > developer on this > > > > list, > > > > > > I've put some more thought into this and have a bit of time > to reply. > > > So here goes. > > > > > > The first thing I'm going to do is demonstrate why I feel > this is a > > > bad spec. Please understand that this is not a criticism of > anyone in > > > particular. I'm merely using this as an example of specs > that don't > > > add any value. > > > > > > Take a look at the spec again: > > > > > > > > > describe SomeModel do > > > it_has_many :widgets, :destroy => :null, :class_name => > "BaseWidget" > > > it_has_one :fuzzbucket > > > it_belongs_to :another_model > > > end > > > > > > Change 'describe' to 'class' and remove 'do' from the first > line. > > > Then remove the 'it_' from the next three lines. At this > point you > > > have the exact implementation of the class. > > > > > > I don't know about you, but that bothers the hell out of me. > > > > > > The concrete benefits of object-level specification are, in > my mind, that it > > > - helps you design your code well > > > - leaves behind regression tests > > > - provides executable examples of how to use code > > > > > > Often when we write specs we have to balance those goals...for > > > example, one major criticism of using mocks is that tests > that use > > > mocks don't act as effective regression tests. That's a valid > > > criticism in certain contexts, but you'll find that most > people who > > > make such criticisms are being myopic - they either don't > understand > > > or don't share the other goals, and so write the technique > off all > > > together. > > > > > > Besides the fact that the given association helpers duplicate > the > > > implementation to an i-t-underscore, what else is wrong with > them? I > > > would argue that they provide 0 value in all three categories. > > > > > > They don't help drive the design. You either need widgets or > you > > > don't. If you decide you do, you add a declaration to the > > > implementation. Done. There was never any question about > how to > > > design it. Rails made that decision for you. > > > > > > They have no value as regression tests. How likely is it > that any of > > > that code will break? Not likely at all. It's not like > anyone's ever > > > going to go in there and change the behavior, because there > is no > > > behavior, other than that which is abstracted away by Rails > (thus > > > already thoroughly tested). If you make any change to the > > > implementation then the specs will fail...so they're brittle > without > > > providing any value. > > > > > > The lack of documentation value should be obvious. The specs > don't > > > show you how to use the objects together. You have to know > how Rails > > > associations work. And you get absolutely no information > from the > > > spec that you don't get from the implementation itself. > > > > > > Hopefully that clarifies why I don't feel that specs like > these are > > > valuable. I also hope that this helps others develop > heuristics for > > > when to write/delete/ignore tests. > > > > > > With that out of the way, how would I specify this SomeModel > class? > > > Well, if the class is as given and there's no business logic, > then I > > > would only write a couple specs for SomeModel directly. > These would > > > be specs for the widgets association. > > > > > > describe SomeModel, "widgets" do > > > before(:each) do > > > @model = SomeModel.create! > > > BaseWidget.create! :some_model_id => @model.id > > > end > > > > > > it "should find BaseWidgets" do > > > @model.should have(1).widget > > > end > > > > > > it "should nullify keys when deleting the widgets" do > > > lambda { @model.widgets.destroy_all }.should_not change > (BaseWidget, :count) > > > @model.should have(0).widgets > > > end > > > end > > > > > > The reason I would do this is because there's a greater > chance that > > > some of this stuff could break. None of the other > associations will. > > > > > > Looking back at this, I'm not sure that I would write the second > > > example. The reason I might not write it is that I don't > think I have > > > enough information. The foreign keys get nulled out when I call > > > #destroy_all, but that's something that I know from the has_many > > > declaration, and that I know works. My real question at this > point is > > > WHY I want the keys nulled out instead of just deleting the > records. > > > Do I have some requirement in the system that these associations > > > should be broken, but the child records should stick around? > If so, I > > > should have another spec that demonstrates that behavior. > > > > > > These associations *should* be tested, but they should be tested > > > indirectly from _somewhere else_. They're not important > enough to > > > deserve tests at such a low granularity. They should be > tested via an > > > acceptance test where a view iterates through them, or some > test which > > > calls a DB aggregate method on the proxy. They don't have any > > > interesting behavior on their own, and we are concerned > primarily with > > > behavior. > > > > > > Does that help? > > > > > > Pat > > > > > > > > > > > > > -- > > Zach Dennis > > http://www.continuousthinking.com > > _______________________________________________ > > > > > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Thu Apr 3 10:21:45 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 3 Apr 2008 10:21:45 -0400 Subject: [rspec-devel] git layout / naming Message-ID: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> Hi all, With the move to git, we're going to break up the rspec project into four repositories. Here's the current thinking: rspec (for the rspec gem/plugin) rspec-rails (for the rspec-rails gem/plugin) RSpec.tmbundle rspec-dev (for website and uber-build) rspec-dev would include the other three as git submodules, so if you're an rspec developer/contributor you can just pull that repo. For those unfamiliar w/ git-submodules, there are a couple of gotchas, but once you understand the flow, it's quite simple. Directions will be available on the website. For everyone else, the gems/plugins (your choice) would be rspec and rspec-rails. Feedback requested. Cheers, David From james.deville at gmail.com Thu Apr 3 16:01:22 2008 From: james.deville at gmail.com (James Deville) Date: Thu, 3 Apr 2008 13:01:22 -0700 Subject: [rspec-devel] git layout / naming In-Reply-To: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> References: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> Message-ID: <26AE61B1-B268-4B5F-8051-76A3A02D225C@gmail.com> I like it. It separates the projects a little better. JD On Apr 3, 2008, at 7:21 AM, David Chelimsky wrote: > Hi all, > > With the move to git, we're going to break up the rspec project into > four repositories. Here's the current thinking: > > rspec (for the rspec gem/plugin) > rspec-rails (for the rspec-rails gem/plugin) > RSpec.tmbundle > rspec-dev (for website and uber-build) > > rspec-dev would include the other three as git submodules, so if > you're an rspec developer/contributor you can just pull that repo. For > those unfamiliar w/ git-submodules, there are a couple of gotchas, but > once you understand the flow, it's quite simple. Directions will be > available on the website. > > For everyone else, the gems/plugins (your choice) would be rspec and > rspec-rails. > > Feedback requested. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From ben at benmabey.com Thu Apr 3 23:52:56 2008 From: ben at benmabey.com (Ben Mabey) Date: Thu, 03 Apr 2008 21:52:56 -0600 Subject: [rspec-devel] pull or patch? Message-ID: <47F5A618.8040801@benmabey.com> Hello, With the move to github should we still be sending in diffs as patches or should we just be making pull requests? Thanks, Ben From dchelimsky at gmail.com Fri Apr 4 00:04:51 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 4 Apr 2008 00:04:51 -0400 Subject: [rspec-devel] pull or patch? In-Reply-To: <47F5A618.8040801@benmabey.com> References: <47F5A618.8040801@benmabey.com> Message-ID: <57c63afe0804032104i598b319fv6acd1f79e49d576@mail.gmail.com> On Thu, Apr 3, 2008 at 11:52 PM, Ben Mabey wrote: > Hello, > With the move to github should we still be sending in diffs as patches > or should we just be making pull requests? We definitely still want tickets at http://rspec.lighthouseapp.com, but a link to the appropriate commit at github is preferable to a diff. Cheers, David > > Thanks, > Ben From dchelimsky at gmail.com Fri Apr 4 09:23:01 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 4 Apr 2008 09:23:01 -0400 Subject: [rspec-devel] Welcome Pat Maddox Message-ID: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> Hi all, I'm pleased to announce that Pat Maddox is joining the RSpec Development Team. As you may already know, Pat has been contributing great patches and participation on the rspec-users and rspec-devel mailing lists for quite some time. He has demonstrated a deep understanding of BDD in general, and specifically as it applies to Rails, which has certainly posed some of the more interesting questions on our mailing lists. We are all excited to have Pat on board and look forward to his continued contribution. Cheers, David From mailing_lists at railsnewbie.com Fri Apr 4 10:06:30 2008 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Fri, 4 Apr 2008 10:06:30 -0400 Subject: [rspec-devel] Welcome Pat Maddox In-Reply-To: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> References: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> Message-ID: On Apr 4, 2008, at 9:23 AM, David Chelimsky wrote: > Hi all, > > I'm pleased to announce that Pat Maddox is joining the RSpec > Development Team. > > As you may already know, Pat has been contributing great patches and > participation on the rspec-users and rspec-devel mailing lists for > quite some time. He has demonstrated a deep understanding of BDD in > general, and specifically as it applies to Rails, which has certainly > posed some of the more interesting questions on our mailing lists. > > We are all excited to have Pat on board and look forward to his > continued contribution. > Awesome Pat - congratulations (I was wondering why I saw you invited on in github last night). We all appreciate your patches - so we look forward to seeing many more! Scott From bryansray at gmail.com Fri Apr 4 10:30:55 2008 From: bryansray at gmail.com (Bryan Ray) Date: Fri, 4 Apr 2008 09:30:55 -0500 Subject: [rspec-devel] Welcome Pat Maddox In-Reply-To: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> References: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> Message-ID: <29a0119e0804040730o54af6663m4466a85ad7d3bb0d@mail.gmail.com> Congratulations, man. On Fri, Apr 4, 2008 at 8:23 AM, David Chelimsky wrote: > Hi all, > > I'm pleased to announce that Pat Maddox is joining the RSpec Development > Team. > > As you may already know, Pat has been contributing great patches and > participation on the rspec-users and rspec-devel mailing lists for > quite some time. He has demonstrated a deep understanding of BDD in > general, and specifically as it applies to Rails, which has certainly > posed some of the more interesting questions on our mailing lists. > > We are all excited to have Pat on board and look forward to his > continued contribution. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Bryan Ray http://www.bryanray.net "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080404/823e2219/attachment.html From coreyhaines at gmail.com Fri Apr 4 10:45:38 2008 From: coreyhaines at gmail.com (Corey Haines) Date: Fri, 4 Apr 2008 10:45:38 -0400 Subject: [rspec-devel] Welcome Pat Maddox In-Reply-To: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> References: <57c63afe0804040623k6fb1fe02v3eca214773424bf4@mail.gmail.com> Message-ID: <6bdacb70804040745w1c294783o88b673d810c9b0e1@mail.gmail.com> Congrats and keep up the good stuff coming! Don't let the development take time away from the blogging, though. :) On Fri, Apr 4, 2008 at 9:23 AM, David Chelimsky wrote: > Hi all, > > I'm pleased to announce that Pat Maddox is joining the RSpec Development > Team. > > As you may already know, Pat has been contributing great patches and > participation on the rspec-users and rspec-devel mailing lists for > quite some time. He has demonstrated a deep understanding of BDD in > general, and specifically as it applies to Rails, which has certainly > posed some of the more interesting questions on our mailing lists. > > We are all excited to have Pat on board and look forward to his > continued contribution. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- http://www.coreyhaines.com The Internet's Premiere source of information about Corey Haines -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080404/6a1bef0c/attachment.html From pergesu at gmail.com Fri Apr 4 16:21:31 2008 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 4 Apr 2008 13:21:31 -0700 Subject: [rspec-devel] Some weirdness with the repo Message-ID: <810a540e0804041321j795f584cgdb8c918e7fd82cff@mail.gmail.com> Hey everyone, The rspec-devel repo was in a funky state. Both rspec and rspec-rails were added as submodules, but the rspec-rails directory had some files already committed to it. This meant that if you branched the parent repo or rspec-rails, they were tied together and commits would go into the master only. I fixed this by trashing the rspec-rails directory and re-adding it as a submodule. You can partly see the problem by looking at the history: http://github.com/dchelimsky/rspec-dev/tree/10c789caa5eb366921a2bf388e6d3c781c85d674/example_rails_app/vendor/plugins http://github.com/dchelimsky/rspec-dev/tree/master/example_rails_app/vendor/plugins As you can see in the latest one, there's no mention of rspec or rspec-rails, which is how it should be. Updating your code should probably Just Work, but if you notice any wonkiness then you're probably best off just doing a fresh clone. Pat From joe at pinkpucker.net Fri Apr 4 16:23:29 2008 From: joe at pinkpucker.net (Joe Van Dyk) Date: Fri, 4 Apr 2008 13:23:29 -0700 Subject: [rspec-devel] git layout / naming In-Reply-To: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> References: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> Message-ID: Works for me. On Thu, Apr 3, 2008 at 7:21 AM, David Chelimsky wrote: > Hi all, > > With the move to git, we're going to break up the rspec project into > four repositories. Here's the current thinking: > > rspec (for the rspec gem/plugin) > rspec-rails (for the rspec-rails gem/plugin) > RSpec.tmbundle > rspec-dev (for website and uber-build) > > rspec-dev would include the other three as git submodules, so if > you're an rspec developer/contributor you can just pull that repo. For > those unfamiliar w/ git-submodules, there are a couple of gotchas, but > once you understand the flow, it's quite simple. Directions will be > available on the website. > > For everyone else, the gems/plugins (your choice) would be rspec and > rspec-rails. > > Feedback requested. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From pergesu at gmail.com Fri Apr 4 16:52:39 2008 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 4 Apr 2008 13:52:39 -0700 Subject: [rspec-devel] Some weirdness with the repo In-Reply-To: <810a540e0804041321j795f584cgdb8c918e7fd82cff@mail.gmail.com> References: <810a540e0804041321j795f584cgdb8c918e7fd82cff@mail.gmail.com> Message-ID: <810a540e0804041352n2e308dd3p7224c13d03806f9a@mail.gmail.com> On Fri, Apr 4, 2008 at 1:21 PM, Pat Maddox wrote: > Hey everyone, > > The rspec-devel repo was in a funky state. Both rspec and rspec-rails > were added as submodules, but the rspec-rails directory had some files > already committed to it. This meant that if you branched the parent > repo or rspec-rails, they were tied together and commits would go into > the master only. I fixed this by trashing the rspec-rails directory > and re-adding it as a submodule. > > You can partly see the problem by looking at the history: > http://github.com/dchelimsky/rspec-dev/tree/10c789caa5eb366921a2bf388e6d3c781c85d674/example_rails_app/vendor/plugins > http://github.com/dchelimsky/rspec-dev/tree/master/example_rails_app/vendor/plugins > > As you can see in the latest one, there's no mention of rspec or > rspec-rails, which is how it should be. > > Updating your code should probably Just Work, but if you notice any > wonkiness then you're probably best off just doing a fresh clone. > > Pat > I found a potential source of the problem. When you commit a submodule, you have to go back to the parent and add the submodule so that it knows which commit to link to. If you do git add example_rails_app/vendor/plugins/rspec-rails then it's fine, but if you do git add example_rails_app/vendor/plugins/rspec-rails/ (notice the trailing slash) then it blows away the submodule and just adds the files. I'm investigating to see if there's a way we can protect against that...but in the mean time just be careful, or only use "git commit -a" Pat From philodespotos at gmail.com Fri Apr 4 23:56:47 2008 From: philodespotos at gmail.com (Kyle Hargraves) Date: Fri, 4 Apr 2008 22:56:47 -0500 Subject: [rspec-devel] Some weirdness with the repo In-Reply-To: <810a540e0804041352n2e308dd3p7224c13d03806f9a@mail.gmail.com> References: <810a540e0804041321j795f584cgdb8c918e7fd82cff@mail.gmail.com> <810a540e0804041352n2e308dd3p7224c13d03806f9a@mail.gmail.com> Message-ID: <60f3810c0804042056i2507d5f3vaf1bc6c6fde84389@mail.gmail.com> Hey, The submodules currently in rspec-dev are linked to dchelimsky's private push url, so those of us without access can't run submodule update. The submodules have to be pointed to the git:// urls. Then as devs with commit bits you can add another remote referencing the private url and push to that. I think submodules across forks might be weird in the future but I can't quite wrap my head around it. Kyle From dchelimsky at gmail.com Sat Apr 5 00:06:17 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 5 Apr 2008 00:06:17 -0400 Subject: [rspec-devel] Some weirdness with the repo In-Reply-To: <60f3810c0804042056i2507d5f3vaf1bc6c6fde84389@mail.gmail.com> References: <810a540e0804041321j795f584cgdb8c918e7fd82cff@mail.gmail.com> <810a540e0804041352n2e308dd3p7224c13d03806f9a@mail.gmail.com> <60f3810c0804042056i2507d5f3vaf1bc6c6fde84389@mail.gmail.com> Message-ID: <57c63afe0804042106k19a82d35qc7de299bf78b3fb6@mail.gmail.com> On Fri, Apr 4, 2008 at 11:56 PM, Kyle Hargraves wrote: > Hey, > > The submodules currently in rspec-dev are linked to dchelimsky's > private push url, so those of us without access can't run submodule > update. The submodules have to be pointed to the git:// urls. Then as > devs with commit bits you can add another remote referencing the > private url and push to that. I changed these here: http://github.com/dchelimsky/rspec-dev/commit/058e544 Let me know if it works for you. Cheers, David > > I think submodules across forks might be weird in the future but I > can't quite wrap my head around it. > > Kyle > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From philodespotos at gmail.com Sat Apr 5 10:45:05 2008 From: philodespotos at gmail.com (Kyle Hargraves) Date: Sat, 5 Apr 2008 09:45:05 -0500 Subject: [rspec-devel] Some weirdness with the repo In-Reply-To: <57c63afe0804042106k19a82d35qc7de299bf78b3fb6@mail.gmail.com> References: <810a540e0804041321j795f584cgdb8c918e7fd82cff@mail.gmail.com> <810a540e0804041352n2e308dd3p7224c13d03806f9a@mail.gmail.com> <60f3810c0804042056i2507d5f3vaf1bc6c6fde84389@mail.gmail.com> <57c63afe0804042106k19a82d35qc7de299bf78b3fb6@mail.gmail.com> Message-ID: <60f3810c0804050745q30f1a662ua014b1fe0e16f0ae@mail.gmail.com> On Fri, Apr 4, 2008 at 11:06 PM, David Chelimsky wrote: > On Fri, Apr 4, 2008 at 11:56 PM, Kyle Hargraves wrote: > > Hey, > > > > The submodules currently in rspec-dev are linked to dchelimsky's > > private push url, so those of us without access can't run submodule > > update. The submodules have to be pointed to the git:// urls. Then as > > devs with commit bits you can add another remote referencing the > > private url and push to that. > > I changed these here: http://github.com/dchelimsky/rspec-dev/commit/058e544 > > Let me know if it works for you. Yup, all golden. Thanks. k From zach.lists at gmail.com Sat Apr 5 13:39:16 2008 From: zach.lists at gmail.com (Zach Moazeni) Date: Sat, 5 Apr 2008 13:39:16 -0400 Subject: [rspec-devel] rspec_on_rails, speccing models, adding it helpers... In-Reply-To: <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> References: <85d99afe0804011429t33f1ad3ida286868e7f972cc@mail.gmail.com> <57c63afe0804011509g6261e156s39b395a4200ee191@mail.gmail.com> <810a540e0804011538t2f5f62c8ode9e2c20e3f9aea@mail.gmail.com> <85d99afe0804011620p228ee5f1m35ba5d8e03efd4ae@mail.gmail.com> <810a540e0804021711q3788b1c5s6acb98d9cfd43b94@mail.gmail.com> Message-ID: <1F034F35-6BDA-4F11-9DA0-8E3E91991A2A@gmail.com> Pat, I appreciate your time in forming your thoughts and putting together a well reasoned reply. Yet there are a few areas where I think tests like these are valuable. (Please note, this is not the original poster, even if we share the same first name) > Change 'describe' to 'class' and remove 'do' from the first line. > Then remove the 'it_' from the next three lines. At this point you > have the exact implementation of the class. > > I don't know about you, but that bothers the hell out of me. This doesn't actually bug me as much. My company sometimes writes software for some pretty dumb users, and I mean that with kindness. Imagine a form with the following fields: - First name - Last name - Email I don't know how many submissions I've seen where they've entered "Bob " or "jacob at foo.com ". Notice the spaces at the end. So most often I write classes like: class SomeObj < ActiveRecord::Base def first_name=(first_name) self[:first_name] = first_name.nil? ? nil : first_name.strip end ... (repeated for last_name and email) end And from writing this same code many many times, I've moved to. class SomeObj < ActiveRecord::Base strips :first_name, :last_name, :email end Naturally my spec was describe SomeObj do it "should set the first name to nil if nil" do obj = SomeObj.new(:first_name => nil) obj.first_name.should be_nil end it "should strip the first name if containing spaces " do obj = SomeObj.new(:first_name => "foo ") obj.first_name.should == "foo" end ...(repeated for last name and email) end Obviously you could (and maybe should) test "obj[:first_name]" to be more specific. So being a lazy developer, I changed this common occurring spec into describe SomeObj do should_strip :first_name, :last_name, :email end This is an example where the implementation and the spec both appear clones, yet I feel they are valuable. > -helps you design your code well Not going to argue this point, because I don't think the spec does squat for this goal. > - provides executable examples of how to use code Although the implementation of the helper "should_strip()" is a little hard to read from the code standpoint, it does create the individual tests. And the spec output is: User - should set the first name to nil if nil - should strip the first name if containing spaces - should set the last name to nil if nil - should strip the last name if containing spaces - should set the email to nil if nil - should strip the email if containing spaces So if the spec breaks I get feedback on what is broken. Which also feels pretty descriptive. That doesn't explain _how_ it can break though, and I feel that ties into the next goal: > leaves behind regression tests It came to pass that another developer added this: class SomeObj < ActiveRecord::Base strips :first_name, :last_name, :email def first_name=(first_name) self[:first_name] = first_name do_some_business_logic_on_setter_of_first_name(first_name) end end Which broke the behavior of the object with which the "should strip the first name if containing spaces" failed. > If you make any change to the implementation then the specs will > fail...so they're brittle without providing any value. I have a hard time grappling with this topic, as it's a very recurring theme in mock testing. But I guess I don't see describe SomeModel do it_has_many :widgets, :destroy => :null, :class_name => "BaseWidget" end any more brittle than class SomeModel do def self.foo(bar) AnotherClass.baz(bar) end end describe SomeModel do describe "#foo" do it "should delegate to AnotherClass#baz" do AnotherClass.stubs(:baz).with("something").returns("something different") SomeModel.foo("something").should == "something different" end end end Yet I find a lot of value in that test (given adequate reasons why it's designed that way). I think this reasoning still applies to the model relationships. I agree there isn't a lot of bang for the buck, but I see there is value. I like the fact it stresses the relationship at a basic level. So to bring the argument full circle: > The concrete benefits of object-level specification are, in my mind, > that it > - helps you design your code well Not disagreeing > - leaves behind regression tests - The scenario above (i.e. adding a method that collides with rails- added behavior) - Stressing the basic add / remove functionality as you develop more complex validation rules on that collection. (e.g. Can't have more than x, Can't have a member in the set of y) - Stressing foreign key constraints from bubbled exceptions from the database (though I think our company is in the minority on that one) > - provides executable examples of how to use code - Declarative error messages (from the spec titles). An example spec doc from our existing project using our version of model behaviors: User relationships - should have many descriptions - should destroy descriptions when deleted - should have many photos - should destroy photos when deleted - should have many projects A couple final notes: - I don't disagree that some of these scenarios could be tested at a higher level, or if something changes, higher level tests will catch them. It's just been my experience that when leaning on higher level tests too much, too many things slip through. Or the verbosity of individual tests becomes a bitch. - Our version of "should_have_many" "should_belong_to", etc, touches the database, and doesn't just check manipulated methods on the model. I find that much more valuable. - I think these helpers needs to remain with basic functionality (Defining the relationships and effects of deletion), any more needs to be in custom specs. - In a perfect world, I would see Rails Core, and other plugin developers to write such declarative behavior helpers along with their declarative code, but I don't think that's at all practical. - While I'm not totally sold on the "Double-entry bookkeeping" argument with regards to testing, I feel there is a bit of that creeping in. For good or worse. - Not intending this reply to be a straw man, but can't articulate what's in my head without bringing another example into the mix. Sorry if it confuses more than helps. -Zach From james at imaj.es Thu Apr 3 10:38:33 2008 From: james at imaj.es (James Cox) Date: Thu, 3 Apr 2008 16:38:33 +0200 Subject: [rspec-devel] git layout / naming In-Reply-To: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> References: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> Message-ID: <44A5F470-C24F-4F90-9897-C0AC477FEC5A@imaj.es> This sounds really awesome! git seems so simple to create all this kind of stuff. On 3 Apr 2008, at 16:21, David Chelimsky wrote: > Hi all, > > With the move to git, we're going to break up the rspec project into > four repositories. Here's the current thinking: > > rspec (for the rspec gem/plugin) > rspec-rails (for the rspec-rails gem/plugin) > RSpec.tmbundle > rspec-dev (for website and uber-build) > > rspec-dev would include the other three as git submodules, so if > you're an rspec developer/contributor you can just pull that repo. For > those unfamiliar w/ git-submodules, there are a couple of gotchas, but > once you understand the flow, it's quite simple. Directions will be > available on the website. > > For everyone else, the gems/plugins (your choice) would be rspec and > rspec-rails. > > Feedback requested. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From revurikarna at gmail.com Wed Apr 2 12:24:57 2008 From: revurikarna at gmail.com (revuri karunakar) Date: Wed, 2 Apr 2008 21:54:57 +0530 Subject: [rspec-devel] Please help me regarding Story Runner with session problems Message-ID: Hi maddox, I'm having the session handling issue in story runner. Small description about my applications and problem My application was integrated with single sign on (SSO) application. Both applications are developed in rails (SSO, Normal application (i.e second)) If any user logged into sso application he can directly access the second application. If any one try to access the second application , it will automatically redirect to sso application (i.e login page). I have written the stories successfully for sso application. but when we write the stories to second application we getting the problems regarding session. I.e in my application every controller having before_filter :login_required which was defined in the plugins(in both applications) We are checking the sessions and cookies in the method When we call the actions from second application , it checking the sessions and cookies but it don't find anything so we are getting the problem we have tried directly to assign the session variables in given block of story i.e request.session['current_user'] = User.find(1) controller.stub!(:login_required).and_return(@user) template.stub!(:login_required).and_return(@user) We did't solve this issue in stories , (FYI we have solved this issue in rspecs using the controller.stub!(:login_required).and_return(@user)) main problem is we are unable to access the session variables in the story (i.e in the when block) Please give your ideas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080402/11fd2876/attachment.html From philodespotos at gmail.com Mon Apr 7 22:52:08 2008 From: philodespotos at gmail.com (Kyle Hargraves) Date: Mon, 7 Apr 2008 21:52:08 -0500 Subject: [rspec-devel] rspec autotest failures Message-ID: <60f3810c0804071952p1d499a86sfacfe9efdd6cd112@mail.gmail.com> Currently (eefc5c3c), rspec's specs are failing for me when run inside autotest. They pass if you run the suite using `rake spec` or `bin/spec -O spec/spec.opts spec`, but if you specify all of the files to run (as autotest does), the failures occur again. Output from all 4 methods: http://pastie.caboo.se/176977 Platform is Leopard with latest rspec repo from github.com/dchelimsky, ruby 1.8.6p110 from macports, and ZenTest 3.9.2 (tho autotest is not the culprit; as run #4 shows, it happens directly from the shell, too). Any other info that would be useful? Can anyone else reproduce these failures? Kyle From dchelimsky at gmail.com Tue Apr 8 00:39:55 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 8 Apr 2008 00:39:55 -0400 Subject: [rspec-devel] rspec autotest failures In-Reply-To: <60f3810c0804071952p1d499a86sfacfe9efdd6cd112@mail.gmail.com> References: <60f3810c0804071952p1d499a86sfacfe9efdd6cd112@mail.gmail.com> Message-ID: <57c63afe0804072139i349b8ef2ne45b5e7d26eccd18@mail.gmail.com> On Mon, Apr 7, 2008 at 10:52 PM, Kyle Hargraves wrote: > Currently (eefc5c3c), rspec's specs are failing for me when run inside autotest. > > They pass if you run the suite using `rake spec` or `bin/spec -O > spec/spec.opts spec`, but if you specify all of the files to run (as > autotest does), the failures occur again. > > Output from all 4 methods: http://pastie.caboo.se/176977 > > Platform is Leopard with latest rspec repo from github.com/dchelimsky, > ruby 1.8.6p110 from macports, and ZenTest 3.9.2 (tho autotest is not > the culprit; as run #4 shows, it happens directly from the shell, > too). Any other info that would be useful? > > Can anyone else reproduce these failures? Yep. Same deal. Looking into it. > > Kyle > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Wed Apr 9 13:43:57 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 9 Apr 2008 13:43:57 -0400 Subject: [rspec-devel] rspec at github Message-ID: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> It's official: http://tinyurl.com/5npxxb Git some happiness! Cheers, David From george at benevolentcode.com Wed Apr 9 14:12:09 2008 From: george at benevolentcode.com (George Anderson) Date: Wed, 9 Apr 2008 14:12:09 -0400 Subject: [rspec-devel] [rspec-users] rspec at github In-Reply-To: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> Message-ID: <782d66f30804091112h31f1ca32gf02c97e36f0faf2@mail.gmail.com> I see your tinyurl and raise you a rubyurl: http://rubyurl.com/xAod "Using git submodules to track vendor/rails" in which the author uses rspec (despite the title) in his well-written exposition on using submodules to track external dependencies. In the comments for that post you'll see Fran?ois Beausoleil is updating Piston to work with SVN and git. I've had no luck getting a recent Piston beta to track a SVN repo (rspec/_on_rails) in the context of a git repo, but YMMV. /g On Wed, Apr 9, 2008 at 1:43 PM, David Chelimsky wrote: > It's official: http://tinyurl.com/5npxxb > > Git some happiness! > > Cheers, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > -- George Anderson BenevolentCode LLC O: (410) 461-7553 C: (410) 218-5185 george at benevolentcode.com From jake.howerton at gmail.com Wed Apr 9 14:20:28 2008 From: jake.howerton at gmail.com (Jake Howerton) Date: Wed, 9 Apr 2008 14:20:28 -0400 Subject: [rspec-devel] [rspec-users] rspec at github In-Reply-To: <782d66f30804091112h31f1ca32gf02c97e36f0faf2@mail.gmail.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> <782d66f30804091112h31f1ca32gf02c97e36f0faf2@mail.gmail.com> Message-ID: <218a05e40804091120k20f9e45bo2530979530ac10d8@mail.gmail.com> George, There is also braid (formerly giston), which can track git and svn repos for your project's git repo. http://evil.che.lu/projects/braid It has essentially the same model as piston and it has been working very well for my projects. -Jake On Wed, Apr 9, 2008 at 2:12 PM, George Anderson wrote: > I see your tinyurl and raise you a rubyurl: > > http://rubyurl.com/xAod > > "Using git submodules to track vendor/rails" in which the author uses > rspec (despite the title) in his well-written exposition on using > submodules to track external dependencies. > > In the comments for that post you'll see Fran?ois Beausoleil is > updating Piston to work with SVN and git. I've had no luck getting a > recent Piston beta to track a SVN repo (rspec/_on_rails) in the > context of a git repo, but YMMV. > > /g > > On Wed, Apr 9, 2008 at 1:43 PM, David Chelimsky wrote: > > It's official: http://tinyurl.com/5npxxb > > > > Git some happiness! > > > > Cheers, > > David > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > -- > > George Anderson > > BenevolentCode LLC > O: (410) 461-7553 > C: (410) 218-5185 > > george at benevolentcode.com > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From mailing_lists at railsnewbie.com Wed Apr 9 22:50:48 2008 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Wed, 9 Apr 2008 22:50:48 -0400 Subject: [rspec-devel] rspec at github In-Reply-To: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> Message-ID: <8491C34A-9AE7-4DAF-959A-C4AACD1F5CC7@railsnewbie.com> On Apr 9, 2008, at 1:43 PM, David Chelimsky wrote: > It's official: http://tinyurl.com/5npxxb > > Git some happiness! > Are you keeping a read only svn repository? If so, how are you doing it (out of curiosity)? Scott From dchelimsky at gmail.com Wed Apr 9 23:13:52 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 9 Apr 2008 23:13:52 -0400 Subject: [rspec-devel] rspec at github In-Reply-To: <8491C34A-9AE7-4DAF-959A-C4AACD1F5CC7@railsnewbie.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> <8491C34A-9AE7-4DAF-959A-C4AACD1F5CC7@railsnewbie.com> Message-ID: <3829E375-C4AF-40DC-9481-09B37A5AE9B7@gmail.com> On Apr 9, 2008, at 10:50 PM, Scott Taylor wrote: > > On Apr 9, 2008, at 1:43 PM, David Chelimsky wrote: > >> It's official: http://tinyurl.com/5npxxb >> >> Git some happiness! >> > > Are you keeping a read only svn repository? If so, how are you doing > it (out of curiosity)? Not in the plan. If a tool emerges (or already exists) that would make this simple to automate we'll consider it, but it's not high priority. From steven at stevenrbaker.com Wed Apr 9 23:18:32 2008 From: steven at stevenrbaker.com (Steven Baker) Date: Wed, 9 Apr 2008 23:18:32 -0400 Subject: [rspec-devel] rspec at github In-Reply-To: <3829E375-C4AF-40DC-9481-09B37A5AE9B7@gmail.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> <8491C34A-9AE7-4DAF-959A-C4AACD1F5CC7@railsnewbie.com> <3829E375-C4AF-40DC-9481-09B37A5AE9B7@gmail.com> Message-ID: <518848B9-22FA-40E2-88AE-2C435A42233B@stevenrbaker.com> >>> It's official: http://tinyurl.com/5npxxb >>> >>> Git some happiness! >>> >> >> Are you keeping a read only svn repository? If so, how are you doing >> it (out of curiosity)? > > Not in the plan. If a tool emerges (or already exists) that would make > this simple to automate we'll consider it, but it's not high priority. I used Tailor to sync Monotone with SVN when RSpec was still on Monotone. If they don't have Git support yet, I'm sure they will soon; it's pretty painless, too. -Steven From pergesu at gmail.com Wed Apr 9 23:20:59 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 9 Apr 2008 20:20:59 -0700 Subject: [rspec-devel] rspec at github In-Reply-To: <3829E375-C4AF-40DC-9481-09B37A5AE9B7@gmail.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> <8491C34A-9AE7-4DAF-959A-C4AACD1F5CC7@railsnewbie.com> <3829E375-C4AF-40DC-9481-09B37A5AE9B7@gmail.com> Message-ID: <810a540e0804092020k4263298fhc28ec2953d8149f6@mail.gmail.com> On Wed, Apr 9, 2008 at 8:13 PM, David Chelimsky wrote: > On Apr 9, 2008, at 10:50 PM, Scott Taylor > > wrote: > > > > > On Apr 9, 2008, at 1:43 PM, David Chelimsky wrote: > > > >> It's official: http://tinyurl.com/5npxxb > >> > >> Git some happiness! > >> > > > > Are you keeping a read only svn repository? If so, how are you doing > > it (out of curiosity)? > > Not in the plan. If a tool emerges (or already exists) that would make > this simple to automate we'll consider it, but it's not high priority. Is there any plan for svn users, or have we dropped svn support entirely at this point? Pat From dchelimsky at gmail.com Wed Apr 9 23:39:52 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 9 Apr 2008 23:39:52 -0400 Subject: [rspec-devel] rspec at github In-Reply-To: <810a540e0804092020k4263298fhc28ec2953d8149f6@mail.gmail.com> References: <57c63afe0804091043o2c1347b6ld23d7246fb73b37@mail.gmail.com> <8491C34A-9AE7-4DAF-959A-C4AACD1F5CC7@railsnewbie.com> <3829E375-C4AF-40DC-9481-09B37A5AE9B7@gmail.com> <810a540e0804092020k4263298fhc28ec2953d8149f6@mail.gmail.com> Message-ID: <4655B64F-8EC1-48FE-A4E8-E08D4695262A@gmail.com> On Apr 9, 2008, at 11:20 PM, "Pat Maddox" wrote: > On Wed, Apr 9, 2008 at 8:13 PM, David Chelimsky > wrote: >> On Apr 9, 2008, at 10:50 PM, Scott Taylor >> >> wrote: >> >>> >>> On Apr 9, 2008, at 1:43 PM, David Chelimsky wrote: >>> >>>> It's official: http://tinyurl.com/5npxxb >>>> >>>> Git some happiness! >>>> >>> >>> Are you keeping a read only svn repository? If so, how are you >>> doing >>> it (out of curiosity)? >> >> Not in the plan. If a tool emerges (or already exists) that would >> make >> this simple to automate we'll consider it, but it's not high >> priority. > > Is there any plan for svn users, or have we dropped svn support > entirely at this point? I see no reason for supporting svn. Devs/contributors should be using git because it simplifies the process. Edge rails users can use script/ plugin and others can just clone the repos and either manage them directly use piston. If, however, as Steve suggests, it is simple to support a read only mirror, I am certainly not opposed to it. If we do, however, I still want to put a stop to svn patches in favor of git. > > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From pergesu at gmail.com Wed Apr 9 23:44:09 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 9 Apr 2008 20:44:09 -0700 Subject: [rspec-devel] Should controller specs fail if you don't make a request? Message-ID: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> A friend of mine just IMed me asking why his spec didn't pass. It looked like describe FooController, "POST create" do it "should build a new Foo" do Foo.should_receive(:new).and_return @mock_foo end end I looked at the spec for a second, then looked at the implementation and it looked fine (he's retrofitting specs on). Looked back at the spec and realized that he never actually made a request. So here's my question: should controller specs fail if no request is made? I have NEVER written a controller spec in which I didn't _intend_ to make a request, though I have forgotten to make a request plenty of times. I had planned to just implement an expectation error if no request is made. But there's a small chance that that's too invasive. I highly doubt it though. Does anyone have specs that would incorrectly fail as a result of this change? Please show code if you do. Pat From brian.takita at gmail.com Thu Apr 10 03:46:11 2008 From: brian.takita at gmail.com (Brian Takita) Date: Thu, 10 Apr 2008 00:46:11 -0700 Subject: [rspec-devel] Issues with submodules in rspec-dev Message-ID: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> Hello, I followed the directions at http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches to initialize and update the submodules in the rspec-dev repo. However, when I run git submodule update, I get: btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update fatal: Needed a single revision Unable to find current revision in submodule path 'RSpec.tmbundle' Has anybody seen this? Thanks, Brian From edvard at majakari.net Thu Apr 10 07:15:41 2008 From: edvard at majakari.net (Edvard Majakari) Date: Thu, 10 Apr 2008 14:15:41 +0300 Subject: [rspec-devel] git layout / naming In-Reply-To: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> References: <57c63afe0804030721w41d03321qd89ad150b93eb92a@mail.gmail.com> Message-ID: > rspec (for the rspec gem/plugin) > rspec-rails (for the rspec-rails gem/plugin) > RSpec.tmbundle > rspec-dev (for website and uber-build) +1. -- "One day, when he was naughty, Mr Bunnsy looked over the hedge into Farmer Fred's field and it was full of fresh green lettuces. Mr Bunnsy, however, was not full of lettuces. This did not seem fair." -- Terry Pratchett, Mr. Bunnsy Has An Adventure From philodespotos at gmail.com Thu Apr 10 08:06:08 2008 From: philodespotos at gmail.com (Kyle Hargraves) Date: Thu, 10 Apr 2008 07:06:08 -0500 Subject: [rspec-devel] Issues with submodules in rspec-dev In-Reply-To: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> References: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> Message-ID: <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> On Thu, Apr 10, 2008 at 2:46 AM, Brian Takita wrote: > Hello, > > I followed the directions at > http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > to initialize and update the submodules in the rspec-dev repo. > > However, when I run git submodule update, I get: > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update > fatal: Needed a single revision > Unable to find current revision in submodule path 'RSpec.tmbundle' > > Has anybody seen this? What version of git are you using? 1.5.4.5 works here, but I suspect the problem might be that the RSpec.tmbundle directory exists when you clone the project, and the submodule update then attempts to read the revision in the path, which of course does not yet exist. rm -rf RSpec.tmbundle and try again, maybe? k From dchelimsky at gmail.com Thu Apr 10 08:46:14 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 10 Apr 2008 08:46:14 -0400 Subject: [rspec-devel] Issues with submodules in rspec-dev In-Reply-To: <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> References: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> Message-ID: <57c63afe0804100546p7cd0c8a3x4b8ecfa4b5691d9d@mail.gmail.com> On Thu, Apr 10, 2008 at 8:06 AM, Kyle Hargraves wrote: > On Thu, Apr 10, 2008 at 2:46 AM, Brian Takita wrote: > > Hello, > > > > I followed the directions at > > http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > > to initialize and update the submodules in the rspec-dev repo. > > > > However, when I run git submodule update, I get: > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update > > fatal: Needed a single revision > > Unable to find current revision in submodule path 'RSpec.tmbundle' > > > > Has anybody seen this? > > What version of git are you using? > > 1.5.4.5 works here Yes - I know that git-submodule is a relatively recent addition and that it has changed over the last couple of versions. I'm running 1.5.4 and just started clean (per the instructions) and all is well. I'll update the docs. > but I suspect the problem might be that the > RSpec.tmbundle directory exists when you clone the project, and the > submodule update then attempts to read the revision in the path, which > of course does not yet exist. rm -rf RSpec.tmbundle and try again, > maybe? > > > > k > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From chris at edendevelopment.co.uk Thu Apr 10 15:43:47 2008 From: chris at edendevelopment.co.uk (Chris Parsons) Date: Thu, 10 Apr 2008 20:43:47 +0100 Subject: [rspec-devel] Should controller specs fail if you don't make a request? In-Reply-To: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> References: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> Message-ID: Hi Pat, On 10 Apr 2008, at 04:44, Pat Maddox wrote: > I had planned to just implement an expectation error if no request is > made. But there's a small chance that that's too invasive. Hmm, interesting. I suppose you might want to write helper functions with the controller that you might want to test independently of a request. Thinking out loud, I guess if I was writing a controller before_filter, say for a cross-concern, I might want to test that in isolation without using a request. Although I'm likely to have any cross-concerns in a module though, which would be tested seperately. Perhaps an orange 'warning' state for a spec would be good, that perhaps you could disable? list << my.two_cents Thanks Chris From ben at benmabey.com Thu Apr 10 18:59:01 2008 From: ben at benmabey.com (Ben Mabey) Date: Thu, 10 Apr 2008 16:59:01 -0600 Subject: [rspec-devel] Should controller specs fail if you don't make a request? In-Reply-To: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> References: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> Message-ID: <47FE9BB5.5070607@benmabey.com> Pat Maddox wrote: > A friend of mine just IMed me asking why his spec didn't pass. It looked like > > describe FooController, "POST create" do > it "should build a new Foo" do > Foo.should_receive(:new).and_return @mock_foo > end > end > > I looked at the spec for a second, then looked at the implementation > and it looked fine (he's retrofitting specs on). Looked back at the > spec and realized that he never actually made a request. > > So here's my question: should controller specs fail if no request is > made? I have NEVER written a controller spec in which I didn't > _intend_ to make a request, though I have forgotten to make a request > plenty of times. > > I had planned to just implement an expectation error if no request is > made. But there's a small chance that that's too invasive. I highly > doubt it though. Does anyone have specs that would incorrectly fail > as a result of this change? Please show code if you do. > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > I think that is a great idea Pat. I have been bitten by this and I have helped many people with the same problem. Someone on #rspec today was actually actually complaining about this very thing. I can't think of a single example of how this change would cause anything to fail incorrectly. Thanks, Ben From zach.dennis at gmail.com Thu Apr 10 21:05:07 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Thu, 10 Apr 2008 21:05:07 -0400 Subject: [rspec-devel] Should controller specs fail if you don't make a request? In-Reply-To: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> References: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> Message-ID: <85d99afe0804101805y1f8c0724xf2c7a7068c01396d@mail.gmail.com> On Wed, Apr 9, 2008 at 11:44 PM, Pat Maddox wrote: > A friend of mine just IMed me asking why his spec didn't pass. It looked > like > > describe FooController, "POST create" do > it "should build a new Foo" do > Foo.should_receive(:new).and_return @mock_foo > end > end > > I looked at the spec for a second, then looked at the implementation > and it looked fine (he's retrofitting specs on). Looked back at the > spec and realized that he never actually made a request. > > So here's my question: should controller specs fail if no request is > made? I have NEVER written a controller spec in which I didn't > _intend_ to make a request, though I have forgotten to make a request > plenty of times. > > I had planned to just implement an expectation error if no request is > made. But there's a small chance that that's too invasive. I highly > doubt it though. Does anyone have specs that would incorrectly fail > as a result of this change? Please show code if you do. > +1.... controllers aren't intended to be used outside the context of a request anyways -- even filters -- so I don't think it would be to invasive for a controller spec, -- Zach Dennis http://www.continuousthinking.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080410/17d5ddbc/attachment.html From ben at benmabey.com Fri Apr 11 00:27:43 2008 From: ben at benmabey.com (Ben Mabey) Date: Thu, 10 Apr 2008 22:27:43 -0600 Subject: [rspec-devel] Setting up rspec-rails for dev probelm Message-ID: <47FEE8BF.6040707@benmabey.com> Hi, I'm trying to set up my environment so I can make some changes to rspec-rails. I have everything setup with rspec-dev and the git submodules and I can run the entire spec suite. I can also run rspec's specs separately and the example_rails_app specs separately. However, when I try to run the specs (via autotest) in rspec-dev/example_rails_app/vendor/plugins/rspec-rails I get: ############################################################################ Your RSpec on Rails plugin is incompatible with your installed RSpec. RSpec : 20080131122909 RSpec on Rails : 20080328014754 Make sure your RSpec on Rails plugin is compatible with your RSpec gem. See http://rspec.rubyforge.org/documentation/rails/install.html for details. ############################################################################ I realize that the rpsec version is coming from my gem 1.1.3 installed. Looking at the spec_helper.rb in rpec-rails it looks like it is trying to include the dev version but... it obviously isn't working for me. What do I need to do get this to work on my box? Any advice would be appreciated. Thanks, Ben From edvard at majakari.net Fri Apr 11 01:43:59 2008 From: edvard at majakari.net (Edvard Majakari) Date: Fri, 11 Apr 2008 08:43:59 +0300 Subject: [rspec-devel] Should controller specs fail if you don't make a request? In-Reply-To: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> References: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> Message-ID: On Thu, Apr 10, 2008 at 6:44 AM, Pat Maddox wrote: > A friend of mine just IMed me asking why his spec didn't pass. It looked like > > describe FooController, "POST create" do > it "should build a new Foo" do > Foo.should_receive(:new).and_return @mock_foo > end > end I've had the same problem a few times, though I think I found out the reason quickly enough. Still, I think it's a good idea. But to be certain, maybe there should be an option for ignoring the missing request from a spec. Otherwise, maybe a warning should be emitted. -- "One day, when he was naughty, Mr Bunnsy looked over the hedge into Farmer Fred's field and it was full of fresh green lettuces. Mr Bunnsy, however, was not full of lettuces. This did not seem fair." -- Terry Pratchett, Mr. Bunnsy Has An Adventure From ben at benmabey.com Fri Apr 11 02:10:27 2008 From: ben at benmabey.com (Ben Mabey) Date: Fri, 11 Apr 2008 00:10:27 -0600 Subject: [rspec-devel] Setting up rspec-rails for dev probelm In-Reply-To: <47FEE8BF.6040707@benmabey.com> References: <47FEE8BF.6040707@benmabey.com> Message-ID: <47FF00D3.6060509@benmabey.com> Ben Mabey wrote: > Hi, > I'm trying to set up my environment so I can make some changes to > rspec-rails. I have everything setup with rspec-dev and the git > submodules and I can run the entire spec suite. > I can also run rspec's specs separately and the example_rails_app specs > separately. However, when I try to run the specs (via autotest) in > rspec-dev/example_rails_app/vendor/plugins/rspec-rails I get: > > ############################################################################ > Your RSpec on Rails plugin is incompatible with your installed RSpec. > > RSpec : 20080131122909 > RSpec on Rails : 20080328014754 > > Make sure your RSpec on Rails plugin is compatible with your RSpec gem. > See http://rspec.rubyforge.org/documentation/rails/install.html for details. > ############################################################################ > > > I realize that the rpsec version is coming from my gem 1.1.3 installed. > Looking at the spec_helper.rb in rpec-rails it looks like it is trying > to include the dev version but... it obviously isn't working for me. > > What do I need to do get this to work on my box? Any advice would be > appreciated. > > Thanks, > > Ben > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > So, I worked around this by just symlinking my dev version of rspec into the gems dir. This worked but now all the specs fail with a SQLite3::SQLException. When you work on rspec-rails how do you run the specs just for that? I must have something set up wrong... The first time I tried to run the specs I was told that rspec-dev/example_rails_app/spec/spec_helper didn't exist. I noticed that this file is being excluded in the repo by .gitignore so I made my own with the 'generate rspec' command. Do I need something custom in that file to allow me to run the specs in rspec-dev/example_rails_app/vendor/plugins/rspec-rails? Sorry for all my questions, I'm just having a hard time getting these to run outside of the pre_commit task. Thanks in advance, Ben From ben at benmabey.com Fri Apr 11 02:55:48 2008 From: ben at benmabey.com (Ben Mabey) Date: Fri, 11 Apr 2008 00:55:48 -0600 Subject: [rspec-devel] Setting up rspec-rails for dev probelm In-Reply-To: <47FF00D3.6060509@benmabey.com> References: <47FEE8BF.6040707@benmabey.com> <47FF00D3.6060509@benmabey.com> Message-ID: <47FF0B74.6020105@benmabey.com> Ben Mabey wrote: > Ben Mabey wrote: > >> Hi, >> I'm trying to set up my environment so I can make some changes to >> rspec-rails. I have everything setup with rspec-dev and the git >> submodules and I can run the entire spec suite. >> I can also run rspec's specs separately and the example_rails_app specs >> separately. However, when I try to run the specs (via autotest) in >> rspec-dev/example_rails_app/vendor/plugins/rspec-rails I get: >> >> ############################################################################ >> Your RSpec on Rails plugin is incompatible with your installed RSpec. >> >> RSpec : 20080131122909 >> RSpec on Rails : 20080328014754 >> >> Make sure your RSpec on Rails plugin is compatible with your RSpec gem. >> See http://rspec.rubyforge.org/documentation/rails/install.html for details. >> ############################################################################ >> >> >> I realize that the rpsec version is coming from my gem 1.1.3 installed. >> Looking at the spec_helper.rb in rpec-rails it looks like it is trying >> to include the dev version but... it obviously isn't working for me. >> >> What do I need to do get this to work on my box? Any advice would be >> appreciated. >> >> Thanks, >> >> Ben >> >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> >> > > > So, I worked around this by just symlinking my dev version of rspec into > the gems dir. This worked but now all the specs fail with a > SQLite3::SQLException. > > When you work on rspec-rails how do you run the specs just for that? I > must have something set up wrong... > > The first time I tried to run the specs I was told that > rspec-dev/example_rails_app/spec/spec_helper didn't exist. I noticed > that this file is being excluded in the repo by .gitignore so I made my > own with the 'generate rspec' command. Do I need something custom in > that file to allow me to run the specs in > rspec-dev/example_rails_app/vendor/plugins/rspec-rails? > > Sorry for all my questions, I'm just having a hard time getting these to > run outside of the pre_commit task. > > Thanks in advance, > Ben > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > Ok... Sorry for spamming the list again, but I found the problem with the DB. I was using the in memory SQLLite and the environment file in the example rails file was loading the migrations relative to the app's root. See fix here: http://github.com/bmabey/rspec-dev/commit/391e5f1145f65e81e7281a369b00fb78f542d405 I still need my symlink hack to get it to run the correct version of rspec, but autotest is now working in the rspec-rails dir. :) -Ben From win at wincent.com Fri Apr 11 02:56:07 2008 From: win at wincent.com (Wincent Colaiuta) Date: Fri, 11 Apr 2008 08:56:07 +0200 Subject: [rspec-devel] rspec at github In-Reply-To: References: Message-ID: <28A633F6-D409-456E-A373-06818275D4EF@wincent.com> El 11/4/2008, a las 0:59, David Chelimsky escribi?: > > I see no reason for supporting svn. Devs/contributors should be using > git because it simplifies the process. Edge rails users can use > script/ > plugin and others can just clone the repos and either manage them > directly use piston. > > If, however, as Steve suggests, it is simple to support a read only > mirror, I am certainly not opposed to it. If we do, however, I still > want to put a stop to svn patches in favor of git. I've never done this myself but I know it is not uncommon practice for people to set up a post-commit hook in the repo to automatically propagate commits to a read-only SVN mirror. No additional software required, this would just be a simple shell script; what I don't know is whether github allows users to install such scripts. If you're interested I'd suggest asking on the Git mailing list for advice or examples from people who have done this; I'd imagine that there are quite a few subscribers with experience in this area. Cheers, Wincent PS. Sorry how I break the threading whenever I reply to a message (I'm subscribed to the digest); I'm currently trying to find out if there's a way to override the "In-Reply-To:" header in my mail client so that that won't happen. From dchelimsky at gmail.com Fri Apr 11 07:01:58 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 11 Apr 2008 07:01:58 -0400 Subject: [rspec-devel] Setting up rspec-rails for dev probelm In-Reply-To: <47FEE8BF.6040707@benmabey.com> References: <47FEE8BF.6040707@benmabey.com> Message-ID: On Apr 11, 2008, at 12:27 AM, Ben Mabey wrote: > Hi, > I'm trying to set up my environment so I can make some changes to > rspec-rails. I have everything setup with rspec-dev and the git > submodules and I can run the entire spec suite. Hi Ben. I've updated the directions on http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches . Please give that a read and let me know if it answers your questions here and if you can get everything to run. Cheers, David From matt-lists at reprocessed.org Fri Apr 11 11:19:51 2008 From: matt-lists at reprocessed.org (Matt Patterson) Date: Fri, 11 Apr 2008 16:19:51 +0100 Subject: [rspec-devel] Failing tests in the tip(?) from github Message-ID: <9EC79F33-ADA8-4BB4-8349-4A2B37161319@reprocessed.org> I'm seeing 7 failures when rake spec_html is run in rspec. The error is: > undefined method `step_failed' for # All the specs in question are story-related. spec/spec/story/runner/story_mediator_spec.rb: Spec::Story::Runner::StoryMediator should create a given step if one matches should create a pending step if no given step matches should create a when step if one matches should create a pending step if no when step matches should create a then step if one matches should create a pending step if no 'then' step matches spec/spec/story/runner/story_runner_spec.rb: Spec::Story::Runner::StoryRunner should clean the steps between stories I'm assuming that this is a problem with the standard spec formatter being invoked in place of a story formatter This only seems to be a problem during the HTML report generating run... And only through rake spec_html: running bin/spec spec/spec/story/ runner/story_mediator_spec.rb --format html works fine... Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From pergesu at gmail.com Fri Apr 11 11:40:09 2008 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 11 Apr 2008 08:40:09 -0700 Subject: [rspec-devel] Failing tests in the tip(?) from github In-Reply-To: <9EC79F33-ADA8-4BB4-8349-4A2B37161319@reprocessed.org> References: <9EC79F33-ADA8-4BB4-8349-4A2B37161319@reprocessed.org> Message-ID: <810a540e0804110840j4b558fal5cc5a81f8d19a983@mail.gmail.com> On Fri, Apr 11, 2008 at 8:19 AM, Matt Patterson wrote: > I'm seeing 7 failures when rake spec_html is run in rspec. > > The error is: > > undefined method `step_failed' for > # > All the specs in question are story-related. > > spec/spec/story/runner/story_mediator_spec.rb: > > Spec::Story::Runner::StoryMediator > should create a given step if one matches > should create a pending step if no given step matches > should create a when step if one matches > should create a pending step if no when step matches > should create a then step if one matches > should create a pending step if no 'then' step matches > > > spec/spec/story/runner/story_runner_spec.rb: > > Spec::Story::Runner::StoryRunner > should clean the steps between stories > > I'm assuming that this is a problem with the standard spec formatter > being invoked in place of a story formatter > > This only seems to be a problem during the HTML report generating run... > > And only through rake spec_html: running bin/spec spec/spec/story/ > runner/story_mediator_spec.rb --format html works fine... Yeah, I've experienced that as well. At this point if you want to run the specs you can run "rake spec" from within the plugins/rspec dir, and "rake -f Multirails.rake pre_commit" from the plugins/rspec-rails dir. That should cover most of the stuff. Pat From dchelimsky at gmail.com Fri Apr 11 11:46:59 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 11 Apr 2008 11:46:59 -0400 Subject: [rspec-devel] Failing tests in the tip(?) from github In-Reply-To: <810a540e0804110840j4b558fal5cc5a81f8d19a983@mail.gmail.com> References: <9EC79F33-ADA8-4BB4-8349-4A2B37161319@reprocessed.org> <810a540e0804110840j4b558fal5cc5a81f8d19a983@mail.gmail.com> Message-ID: On Apr 11, 2008, at 11:40 AM, Pat Maddox wrote: > At this point if you want to run > the specs you can run "rake spec" from within the plugins/rspec dir, > and "rake -f Multirails.rake pre_commit" from the plugins/rspec-rails > dir. That should cover most of the stuff. This is all documented at http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches . We'll update that page as we get the uber-pre_commit working again. Cheers, David From matt-lists at reprocessed.org Fri Apr 11 12:23:47 2008 From: matt-lists at reprocessed.org (Matt Patterson) Date: Fri, 11 Apr 2008 17:23:47 +0100 Subject: [rspec-devel] Failing tests in the tip(?) from github In-Reply-To: References: <9EC79F33-ADA8-4BB4-8349-4A2B37161319@reprocessed.org> <810a540e0804110840j4b558fal5cc5a81f8d19a983@mail.gmail.com> Message-ID: <6105428C-5666-4B1A-A4B3-FB6731A39E82@reprocessed.org> On 11 Apr 2008, at 16:46, David Chelimsky wrote: > On Apr 11, 2008, at 11:40 AM, Pat Maddox wrote: >> At this point if you want to run >> the specs you can run "rake spec" from within the plugins/rspec dir, >> and "rake -f Multirails.rake pre_commit" from the plugins/rspec-rails >> dir. That should cover most of the stuff. > > This is all documented at http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > . We'll update that page as we get the uber-pre_commit working again. Aha. I followed that as far as git-submodule, and defaulted to README... Also, contributingpatches doesn't warn you that the ?ber pre_commit is broke... Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From matt-lists at reprocessed.org Fri Apr 11 12:58:37 2008 From: matt-lists at reprocessed.org (Matt Patterson) Date: Fri, 11 Apr 2008 17:58:37 +0100 Subject: [rspec-devel] Failing tests in the tip(?) from github In-Reply-To: References: <9EC79F33-ADA8-4BB4-8349-4A2B37161319@reprocessed.org> <810a540e0804110840j4b558fal5cc5a81f8d19a983@mail.gmail.com> Message-ID: <8CF7CD90-478C-48C8-B182-07D69AD2B2DE@reprocessed.org> On 11 Apr 2008, at 16:46, David Chelimsky wrote: > . We'll update that page as we get the uber-pre_commit working again. Realisation is dawning. Commenting out the call to rspec_options, and uncommenting the original method body, in Spec::Story::run_options makes rake spec_html in rspec core pass again. I'd better get cracking on http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/373 then, hadn't I. Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From bryansray at gmail.com Fri Apr 11 14:34:55 2008 From: bryansray at gmail.com (Bryan Ray) Date: Fri, 11 Apr 2008 13:34:55 -0500 Subject: [rspec-devel] Should controller specs fail if you don't make a request? In-Reply-To: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> References: <810a540e0804092044k69c70533sf0c47fcbb48fe82e@mail.gmail.com> Message-ID: +1 ... I often run in to this same problem, but wouldn't mind seeing an option for displaying some sort of warning (as others have suggested) either. On Apr 9, 2008, at 10:44 PM, Pat Maddox wrote: > A friend of mine just IMed me asking why his spec didn't pass. It > looked like > > describe FooController, "POST create" do > it "should build a new Foo" do > Foo.should_receive(:new).and_return @mock_foo > end > end > > I looked at the spec for a second, then looked at the implementation > and it looked fine (he's retrofitting specs on). Looked back at the > spec and realized that he never actually made a request. > > So here's my question: should controller specs fail if no request is > made? I have NEVER written a controller spec in which I didn't > _intend_ to make a request, though I have forgotten to make a request > plenty of times. > > I had planned to just implement an expectation error if no request is > made. But there's a small chance that that's too invasive. I highly > doubt it though. Does anyone have specs that would incorrectly fail > as a result of this change? Please show code if you do. > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From ben at benmabey.com Fri Apr 11 14:55:53 2008 From: ben at benmabey.com (Ben Mabey) Date: Fri, 11 Apr 2008 12:55:53 -0600 Subject: [rspec-devel] Setting up rspec-rails for dev probelm In-Reply-To: References: <47FEE8BF.6040707@benmabey.com> Message-ID: <47FFB439.9000504@benmabey.com> David Chelimsky wrote: > On Apr 11, 2008, at 12:27 AM, Ben Mabey wrote: > > >> Hi, >> I'm trying to set up my environment so I can make some changes to >> rspec-rails. I have everything setup with rspec-dev and the git >> submodules and I can run the entire spec suite. >> > > Hi Ben. I've updated the directions on http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > . Please give that a read and let me know if it answers your questions > here and if you can get everything to run. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > The updated directions are great. It makes a lot more sense now. Thanks, Ben From brian.takita at gmail.com Sat Apr 12 03:07:18 2008 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 12 Apr 2008 00:07:18 -0700 Subject: [rspec-devel] Issues with submodules in rspec-dev In-Reply-To: <57c63afe0804100546p7cd0c8a3x4b8ecfa4b5691d9d@mail.gmail.com> References: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> <57c63afe0804100546p7cd0c8a3x4b8ecfa4b5691d9d@mail.gmail.com> Message-ID: <1d7ddd110804120007l1b8f523by534e57ee5094e021@mail.gmail.com> On Thu, Apr 10, 2008 at 5:46 AM, David Chelimsky wrote: > On Thu, Apr 10, 2008 at 8:06 AM, Kyle Hargraves wrote: > > On Thu, Apr 10, 2008 at 2:46 AM, Brian Takita wrote: > > > Hello, > > > > > > I followed the directions at > > > http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > > > to initialize and update the submodules in the rspec-dev repo. > > > > > > However, when I run git submodule update, I get: > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update > > > fatal: Needed a single revision > > > Unable to find current revision in submodule path 'RSpec.tmbundle' > > > > > > Has anybody seen this? > > > > What version of git are you using? > > > > 1.5.4.5 works here > > Yes - I know that git-submodule is a relatively recent addition and > that it has changed over the last couple of versions. I'm running > 1.5.4 and just started clean (per the instructions) and all is well. I'm running 1.5.4.3. I'll try upgrading to the latest version. > > I'll update the docs. > > > > > but I suspect the problem might be that the > > RSpec.tmbundle directory exists when you clone the project, and the > > submodule update then attempts to read the revision in the path, which > > of course does not yet exist. rm -rf RSpec.tmbundle and try again, > > maybe? > > > > > > > > k > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From brian.takita at gmail.com Sat Apr 12 05:23:49 2008 From: brian.takita at gmail.com (Brian Takita) Date: Sat, 12 Apr 2008 02:23:49 -0700 Subject: [rspec-devel] Issues with submodules in rspec-dev In-Reply-To: <1d7ddd110804120007l1b8f523by534e57ee5094e021@mail.gmail.com> References: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> <57c63afe0804100546p7cd0c8a3x4b8ecfa4b5691d9d@mail.gmail.com> <1d7ddd110804120007l1b8f523by534e57ee5094e021@mail.gmail.com> Message-ID: <1d7ddd110804120223s703bf4afxdfc793b14b88479f@mail.gmail.com> On Sat, Apr 12, 2008 at 12:07 AM, Brian Takita wrote: > On Thu, Apr 10, 2008 at 5:46 AM, David Chelimsky wrote: > > On Thu, Apr 10, 2008 at 8:06 AM, Kyle Hargraves wrote: > > > On Thu, Apr 10, 2008 at 2:46 AM, Brian Takita wrote: > > > > Hello, > > > > > > > > I followed the directions at > > > > http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > > > > to initialize and update the submodules in the rspec-dev repo. > > > > > > > > However, when I run git submodule update, I get: > > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init > > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update > > > > fatal: Needed a single revision > > > > Unable to find current revision in submodule path 'RSpec.tmbundle' > > > > > > > > Has anybody seen this? > > > > > > What version of git are you using? > > > > > > 1.5.4.5 works here > > > > Yes - I know that git-submodule is a relatively recent addition and > > that it has changed over the last couple of versions. I'm running > > 1.5.4 and just started clean (per the instructions) and all is well. > I'm running 1.5.4.3. I'll try upgrading to the latest version. Hmm, I got the same issue using git version 1.5.5.29.g7134 So I removed the directory, and cloned again. Now it works. Maybe I messed something up. > > > > > > I'll update the docs. > > > > > > > > > but I suspect the problem might be that the > > > RSpec.tmbundle directory exists when you clone the project, and the > > > submodule update then attempts to read the revision in the path, which > > > of course does not yet exist. rm -rf RSpec.tmbundle and try again, > > > maybe? > > > > > > > > > > > > k > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > _______________________________________________ > > rspec-devel mailing list > > rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From brian.takita at gmail.com Wed Apr 16 00:53:19 2008 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 15 Apr 2008 21:53:19 -0700 Subject: [rspec-devel] Is the pre_commit passing? Message-ID: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> Hello, Just wondering if rake pre_commit is passing for everyone. Its not working for me off of a clean clone. Thanks, Brian From brian.takita at gmail.com Wed Apr 16 00:55:43 2008 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 15 Apr 2008 21:55:43 -0700 Subject: [rspec-devel] Issues with submodules in rspec-dev In-Reply-To: <1d7ddd110804120223s703bf4afxdfc793b14b88479f@mail.gmail.com> References: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> <57c63afe0804100546p7cd0c8a3x4b8ecfa4b5691d9d@mail.gmail.com> <1d7ddd110804120007l1b8f523by534e57ee5094e021@mail.gmail.com> <1d7ddd110804120223s703bf4afxdfc793b14b88479f@mail.gmail.com> Message-ID: <1d7ddd110804152155r1ec7ccc0n608640f11a5699d@mail.gmail.com> On Sat, Apr 12, 2008 at 2:23 AM, Brian Takita wrote: > On Sat, Apr 12, 2008 at 12:07 AM, Brian Takita wrote: > > On Thu, Apr 10, 2008 at 5:46 AM, David Chelimsky wrote: > > > On Thu, Apr 10, 2008 at 8:06 AM, Kyle Hargraves wrote: > > > > On Thu, Apr 10, 2008 at 2:46 AM, Brian Takita wrote: > > > > > Hello, > > > > > > > > > > I followed the directions at > > > > > http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > > > > > to initialize and update the submodules in the rspec-dev repo. > > > > > > > > > > However, when I run git submodule update, I get: > > > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init > > > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update > > > > > fatal: Needed a single revision > > > > > Unable to find current revision in submodule path 'RSpec.tmbundle' > > > > > > > > > > Has anybody seen this? > > > > > > > > What version of git are you using? > > > > > > > > 1.5.4.5 works here > > > > > > Yes - I know that git-submodule is a relatively recent addition and > > > that it has changed over the last couple of versions. I'm running > > > 1.5.4 and just started clean (per the instructions) and all is well. > > I'm running 1.5.4.3. I'll try upgrading to the latest version. > Hmm, I got the same issue using git version 1.5.5.29.g7134 > > So I removed the directory, and cloned again. Now it works. Maybe I > messed something up. I got this to happen again. My initial git submodule update got interrupted. > > > > > > > > > > > > I'll update the docs. > > > > > > > > > > > > > but I suspect the problem might be that the > > > > RSpec.tmbundle directory exists when you clone the project, and the > > > > submodule update then attempts to read the revision in the path, which > > > > of course does not yet exist. rm -rf RSpec.tmbundle and try again, > > > > maybe? > > > > > > > > > > > > > > > > k > > > > _______________________________________________ > > > > rspec-devel mailing list > > > > rspec-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > > _______________________________________________ > > > rspec-devel mailing list > > > rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > From brian.takita at gmail.com Wed Apr 16 00:58:09 2008 From: brian.takita at gmail.com (Brian Takita) Date: Tue, 15 Apr 2008 21:58:09 -0700 Subject: [rspec-devel] Is the pre_commit passing? In-Reply-To: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> References: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> Message-ID: <1d7ddd110804152158r63bbfcx7792ef10203ba54c@mail.gmail.com> On Tue, Apr 15, 2008 at 9:53 PM, Brian Takita wrote: > Hello, Just wondering if rake pre_commit is passing for everyone. > > Its not working for me off of a clean clone. Nm, I missed the "Failing tests in the tip(?) from github" thread. > > Thanks, > Brian > From bryansray at gmail.com Wed Apr 16 00:59:25 2008 From: bryansray at gmail.com (Bryan Ray) Date: Tue, 15 Apr 2008 23:59:25 -0500 Subject: [rspec-devel] Is the pre_commit passing? In-Reply-To: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> References: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> Message-ID: <7C9EC498-FF3B-433C-A3A4-4680710F9ED8@gmail.com> According to David Chelimsky: On Wed, Apr 9, 2008 at 1:48 PM, David Chelimsky wrote: On Wed, Apr 9, 2008 at 2:24 PM, Luis Lavena wrote: > BTW, there is a doc or something to help you get the correct > environment to spec RSpec? I saw your pre-commit stuff, but never > managed to replicate the environment to try it. The pre_commit is not working correctly right now. We're working on it though. _______________________________________________ rspec-users mailing list rspec-users at rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users I have not seen any resolution to it yet. On Apr 15, 2008, at 11:53 PM, Brian Takita wrote: > Hello, Just wondering if rake pre_commit is passing for everyone. > > Its not working for me off of a clean clone. > > Thanks, > Brian > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From matt at aimonetti.net Wed Apr 16 02:56:30 2008 From: matt at aimonetti.net (Matt Aimonetti) Date: Tue, 15 Apr 2008 23:56:30 -0700 Subject: [rspec-devel] using git rspec + rspec-rails edge Message-ID: So here is my problem, I'm working on an app that uses rspec edge and I'm using git + submodules to track your progress. The only issues is that I get the following annoying message: ############################################################################ Your RSpec on Rails plugin is incompatible with your installed RSpec. RSpec : 20080328014754 RSpec on Rails : 20080414041511 Looking at the github repos it doesn't seem I can get a version where both versions match. Are you guys working on that or is there a solution? -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080415/59b5beb9/attachment.html From pergesu at gmail.com Wed Apr 16 04:03:26 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 16 Apr 2008 01:03:26 -0700 Subject: [rspec-devel] using git rspec + rspec-rails edge In-Reply-To: References: Message-ID: <810a540e0804160103q29b65e15na6cff6646c0f8fc8@mail.gmail.com> On Tue, Apr 15, 2008 at 11:56 PM, Matt Aimonetti wrote: > > So here is my problem, I'm working on an app that uses rspec edge and I'm > using git + submodules to track your progress. > > The only issues is that I get the following annoying message: > > ############################################################################ > Your RSpec on Rails plugin is incompatible with your installed RSpec. > > RSpec : 20080328014754 > RSpec on Rails : 20080414041511 > > Looking at the github repos it doesn't seem I can get a version where both > versions match. I just pushed changes to github with new version numbers that match. > Are you guys working on that or is there a solution? If this comes up, and you're pretty sure you've got versions of the plugins that work together, you can just change one of the files to match the other. And if you've got the full rspec-dev repo, you can run "rake touch_revision_storing_files" to auto-generate the version.rb files. Pat From pergesu at gmail.com Wed Apr 16 04:07:22 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 16 Apr 2008 01:07:22 -0700 Subject: [rspec-devel] using git rspec + rspec-rails edge In-Reply-To: <810a540e0804160103q29b65e15na6cff6646c0f8fc8@mail.gmail.com> References: <810a540e0804160103q29b65e15na6cff6646c0f8fc8@mail.gmail.com> Message-ID: <810a540e0804160107s794ed4a7r2b52ae5fcef7dc17@mail.gmail.com> On Wed, Apr 16, 2008 at 1:03 AM, Pat Maddox wrote: > I just pushed changes to github with new version numbers that match. Just in case this wasn't clear enough (sorry, I'm tired), you should be able to update and have everything work fine now. Pat From matt at aimonetti.net Wed Apr 16 04:33:50 2008 From: matt at aimonetti.net (Matt Aimonetti) Date: Wed, 16 Apr 2008 01:33:50 -0700 Subject: [rspec-devel] using git rspec + rspec-rails edge In-Reply-To: <810a540e0804160107s794ed4a7r2b52ae5fcef7dc17@mail.gmail.com> References: <810a540e0804160103q29b65e15na6cff6646c0f8fc8@mail.gmail.com> <810a540e0804160107s794ed4a7r2b52ae5fcef7dc17@mail.gmail.com> Message-ID: Thanks Pat, I did update the submodules and everything worked fine. -Matt On 4/16/08, Pat Maddox wrote: > > On Wed, Apr 16, 2008 at 1:03 AM, Pat Maddox wrote: > > I just pushed changes to github with new version numbers that match. > > > Just in case this wasn't clear enough (sorry, I'm tired), you should > be able to update and have everything work fine now. > > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080416/52ae81c8/attachment.html From pergesu at gmail.com Wed Apr 16 04:35:02 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 16 Apr 2008 01:35:02 -0700 Subject: [rspec-devel] rake git:update Message-ID: <810a540e0804160135l6dcf6fd6s13784c110a969f69@mail.gmail.com> I don't know if any of you guys are using this right now...I made a bunch of changes to it tonight, based on some stuff I discovered about git, submodules, and the workflow that we (or at least I) use. Here's what I think is a pretty natural way to develop... make changes to the plugins, commit go to superproject, commit submodule changes Now to get upstream changes, you can do a couple things. You can't just rebase the parent repo and "git submodule update" because that will blow away the changes you made. You either have to work with the submodules in separate repos and merge them in, or you'd have to rebase the submodules individually. I choose the latter because it's more natural for me to do this all in the same project. Once you've rebased the submodules, you have to commit the submodule refs to the superproject. I didn't really know all of this when I first wrote the git:update task. I thought it was enough to just update the parent and then the submodules. That works fine unless you've got changes that need rebasing, and then it gets all messed up. After playing around with this a bunch I think I came up with a decent way to handle that workflow... but I'd really appreciate it if people could use it and let me know if there are any problems. Most importantly, I'm wondering if this single update command is a viable strategy, or if I'm barking up the wrong tree and should look into a more traditional "lots of repositories with lots of merging" strategy, incurring that overhead. Time for bed. Pat From dchelimsky at gmail.com Wed Apr 16 06:51:41 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 16 Apr 2008 06:51:41 -0400 Subject: [rspec-devel] Issues with submodules in rspec-dev In-Reply-To: <1d7ddd110804152155r1ec7ccc0n608640f11a5699d@mail.gmail.com> References: <1d7ddd110804100046t6357b14fn2e06071294a5d640@mail.gmail.com> <60f3810c0804100506k1a1ec3camfb2af1716bce5f1a@mail.gmail.com> <57c63afe0804100546p7cd0c8a3x4b8ecfa4b5691d9d@mail.gmail.com> <1d7ddd110804120007l1b8f523by534e57ee5094e021@mail.gmail.com> <1d7ddd110804120223s703bf4afxdfc793b14b88479f@mail.gmail.com> <1d7ddd110804152155r1ec7ccc0n608640f11a5699d@mail.gmail.com> Message-ID: <57c63afe0804160351n479500bbuf133a738b8d788c8@mail.gmail.com> On Wed, Apr 16, 2008 at 12:55 AM, Brian Takita wrote: > On Sat, Apr 12, 2008 at 2:23 AM, Brian Takita wrote: > > On Sat, Apr 12, 2008 at 12:07 AM, Brian Takita wrote: > > > On Thu, Apr 10, 2008 at 5:46 AM, David Chelimsky wrote: > > > > On Thu, Apr 10, 2008 at 8:06 AM, Kyle Hargraves wrote: > > > > > On Thu, Apr 10, 2008 at 2:46 AM, Brian Takita wrote: > > > > > > Hello, > > > > > > > > > > > > I followed the directions at > > > > > > http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > > > > > > to initialize and update the submodules in the rspec-dev repo. > > > > > > > > > > > > However, when I run git submodule update, I get: > > > > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule init > > > > > > btakita at btakita-laptop:~/workspace/rspec-dev$ git submodule update > > > > > > fatal: Needed a single revision > > > > > > Unable to find current revision in submodule path 'RSpec.tmbundle' > > > > > > > > > > > > Has anybody seen this? > > > > > > > > > > What version of git are you using? > > > > > > > > > > 1.5.4.5 works here > > > > > > > > Yes - I know that git-submodule is a relatively recent addition and > > > > that it has changed over the last couple of versions. I'm running > > > > 1.5.4 and just started clean (per the instructions) and all is well. > > > I'm running 1.5.4.3. I'll try upgrading to the latest version. > > Hmm, I got the same issue using git version 1.5.5.29.g7134 > > > > So I removed the directory, and cloned again. Now it works. Maybe I > > messed something up. > I got this to happen again. My initial git submodule update got interrupted. I've been using 'rake git:update' from the rspec-dev directory with zero trouble. Have you tried using that? Of course, you can only do it after you've cloned rspec-dev :) > > > > > > > > > > > > > > > > > > > > I'll update the docs. > > > > > > > > > > > > > > > > > but I suspect the problem might be that the > > > > > RSpec.tmbundle directory exists when you clone the project, and the > > > > > submodule update then attempts to read the revision in the path, which > > > > > of course does not yet exist. rm -rf RSpec.tmbundle and try again, > > > > > maybe? > > > > > > > > > > > > > > > > > > > > k From dchelimsky at gmail.com Wed Apr 16 06:52:57 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 16 Apr 2008 06:52:57 -0400 Subject: [rspec-devel] Is the pre_commit passing? In-Reply-To: <7C9EC498-FF3B-433C-A3A4-4680710F9ED8@gmail.com> References: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> <7C9EC498-FF3B-433C-A3A4-4680710F9ED8@gmail.com> Message-ID: <57c63afe0804160352u7dae86dhe6092b38c0175285@mail.gmail.com> On Wed, Apr 16, 2008 at 12:59 AM, Bryan Ray wrote: > According to David Chelimsky: > > On Wed, Apr 9, 2008 at 1:48 PM, David Chelimsky > wrote: > > On Wed, Apr 9, 2008 at 2:24 PM, Luis Lavena > wrote: > > BTW, there is a doc or something to help you get the correct > > environment to spec RSpec? I saw your pre-commit stuff, but > never > > managed to replicate the environment to try it. > > The pre_commit is not working correctly right now. We're working > on it though. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > I have not seen any resolution to it yet. It should be working right now. There are a couple of things that are commented that I have to address, but you should be able to run it. > On Apr 15, 2008, at 11:53 PM, Brian Takita wrote: > > > Hello, Just wondering if rake pre_commit is passing for everyone. > > > > Its not working for me off of a clean clone. > > > > Thanks, > > Brian From dchelimsky at gmail.com Wed Apr 16 08:30:47 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 16 Apr 2008 08:30:47 -0400 Subject: [rspec-devel] rake git:update In-Reply-To: <810a540e0804160135l6dcf6fd6s13784c110a969f69@mail.gmail.com> References: <810a540e0804160135l6dcf6fd6s13784c110a969f69@mail.gmail.com> Message-ID: <57c63afe0804160530u73675e04r915445f49ccbb4d9@mail.gmail.com> I don't know how it happened, but somehow all the changes I've committed to the rspec repo since 4/10 are GONE. Take a look at http://github.com/dchelimsky/rspec-dev/commit/c59041b3b4b1a1bea8c24f8ca79b88bd9c2043cf. This commit was on 4/13 with the message "got uber-pre-commit working." You can see that the rspec repo got updated to commit f3aeaf1a5f7167148d32adf3001e0fc9db37c138. Now look at http://github.com/dchelimsky/rspec/commit/f3aeaf1a5f7167148d32adf3001e0fc9db37c138. GONE. WHAT THE FUCK?????????? This really, really, really has me questioning everything about git and github. Please help me understand why we shouldn't bag the whole thing right this minute. On Wed, Apr 16, 2008 at 4:35 AM, Pat Maddox wrote: > I don't know if any of you guys are using this right now...I made a > bunch of changes to it tonight, based on some stuff I discovered about > git, submodules, and the workflow that we (or at least I) use. > > Here's what I think is a pretty natural way to develop... > make changes to the plugins, commit > go to superproject, commit submodule changes > > Now to get upstream changes, you can do a couple things. You can't > just rebase the parent repo and "git submodule update" because that > will blow away the changes you made. You either have to work with the > submodules in separate repos and merge them in, or you'd have to > rebase the submodules individually. I choose the latter because it's > more natural for me to do this all in the same project. Once you've > rebased the submodules, you have to commit the submodule refs to the > superproject. > > I didn't really know all of this when I first wrote the git:update > task. I thought it was enough to just update the parent and then the > submodules. That works fine unless you've got changes that need > rebasing, and then it gets all messed up. > > After playing around with this a bunch I think I came up with a decent > way to handle that workflow... but I'd really appreciate it if people > could use it and let me know if there are any problems. Most > importantly, I'm wondering if this single update command is a viable > strategy, or if I'm barking up the wrong tree and should look into a > more traditional "lots of repositories with lots of merging" strategy, > incurring that overhead. > > Time for bed. > > Pat > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From bryansray at gmail.com Wed Apr 16 10:08:20 2008 From: bryansray at gmail.com (Bryan Ray) Date: Wed, 16 Apr 2008 09:08:20 -0500 Subject: [rspec-devel] rake git:update In-Reply-To: <57c63afe0804160530u73675e04r915445f49ccbb4d9@mail.gmail.com> References: <810a540e0804160135l6dcf6fd6s13784c110a969f69@mail.gmail.com> <57c63afe0804160530u73675e04r915445f49ccbb4d9@mail.gmail.com> Message-ID: <70F45E06-6BEF-4123-9673-35334E95F5BF@gmail.com> On Apr 16, 2008, at 7:30 AM, David Chelimsky wrote: > I don't know how it happened, but somehow all the changes I've > committed to the rspec repo since 4/10 are GONE. > > Take a look at http://github.com/dchelimsky/rspec-dev/commit/c59041b3b4b1a1bea8c24f8ca79b88bd9c2043cf > . > This commit was on 4/13 with the message "got uber-pre-commit > working." You can see that the rspec repo got updated to commit > f3aeaf1a5f7167148d32adf3001e0fc9db37c138. I'm no git expert by any means, but I don't see that it was created under that ID? > > > Now look at http://github.com/dchelimsky/rspec/commit/f3aeaf1a5f7167148d32adf3001e0fc9db37c138 > . > GONE. > > WHAT THE FUCK?????????? Perhaps someone's repo has this commit from an earlier pull down? Not to doubt you David, but are you sure that commit was made to the rspec repo? I'm not entirely sure I'd believe that a commit just "disappeared." Don't take that the wrong way, buddy. > > > This really, really, really has me questioning everything about git > and github. Please help me understand why we shouldn't bag the whole > thing right this minute. > > On Wed, Apr 16, 2008 at 4:35 AM, Pat Maddox wrote: >> I don't know if any of you guys are using this right now...I made a >> bunch of changes to it tonight, based on some stuff I discovered >> about >> git, submodules, and the workflow that we (or at least I) use. >> >> Here's what I think is a pretty natural way to develop... >> make changes to the plugins, commit >> go to superproject, commit submodule changes >> >> Now to get upstream changes, you can do a couple things. You can't >> just rebase the parent repo and "git submodule update" because that >> will blow away the changes you made. You either have to work with >> the >> submodules in separate repos and merge them in, or you'd have to >> rebase the submodules individually. I choose the latter because it's >> more natural for me to do this all in the same project. Once you've >> rebased the submodules, you have to commit the submodule refs to the >> superproject. >> >> I didn't really know all of this when I first wrote the git:update >> task. I thought it was enough to just update the parent and then the >> submodules. That works fine unless you've got changes that need >> rebasing, and then it gets all messed up. >> >> After playing around with this a bunch I think I came up with a >> decent >> way to handle that workflow... but I'd really appreciate it if people >> could use it and let me know if there are any problems. Most >> importantly, I'm wondering if this single update command is a viable >> strategy, or if I'm barking up the wrong tree and should look into a >> more traditional "lots of repositories with lots of merging" >> strategy, >> incurring that overhead. >> >> Time for bed. >> >> Pat >> _______________________________________________ >> rspec-devel mailing list >> rspec-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-devel >> > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Wed Apr 16 11:25:35 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 16 Apr 2008 11:25:35 -0400 Subject: [rspec-devel] rake git:update In-Reply-To: <70F45E06-6BEF-4123-9673-35334E95F5BF@gmail.com> References: <810a540e0804160135l6dcf6fd6s13784c110a969f69@mail.gmail.com> <57c63afe0804160530u73675e04r915445f49ccbb4d9@mail.gmail.com> <70F45E06-6BEF-4123-9673-35334E95F5BF@gmail.com> Message-ID: <57c63afe0804160825s6dfc942eja5a4c6acc495d819@mail.gmail.com> On Wed, Apr 16, 2008 at 10:08 AM, Bryan Ray wrote: > Perhaps someone's repo has this commit from an earlier pull down? > > Not to doubt you David, but are you sure that commit was made to the > rspec repo? I'm not entirely sure I'd believe that a commit just > "disappeared." Don't take that the wrong way, buddy. No offense taken - we're all learning here. Last night I closed a ticket: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/380. When I closed it, I included an URL that I copied from my browser while looking at the commit on the github site: http://github.com/dchelimsky/rspec/commit/fcb031dffbe36dd216225e7ad6b6e0684ac36297 If you go to that link, you'll see "That page doesn't exist!" I've learned something from conversations w/ the folks on #git @ freenode. First - it is entirely possible that I have no local record of the missing commits, since I pulled from a repo that has no record of them. Assuming that it was a push that Pat did that led to this, he *should* have the commits in his local repo and we should be able to find them using: git fsck --full fcb031dffbe36dd216225e7ad6b6e0684ac36297 If he's already re-created his local repo from github, we're just screwed - unless github has a backup somewhere - but doesn't that defeat the whole purpose of SCM? The fact that a single repository can loose completely any one piece of its history is absolutely ludicrous to me. Mercurial does this correctly in my view. Even if I really, really want to remove something from a repo, I can not. What I can do is clone the repo at an old changeset that I want to make the new HEAD, and then REPLACE the entire repo with the clone. FWIW From chris at edendevelopment.co.uk Wed Apr 16 11:39:23 2008 From: chris at edendevelopment.co.uk (Chris Parsons) Date: Wed, 16 Apr 2008 16:39:23 +0100 Subject: [rspec-devel] rake git:update In-Reply-To: <57c63afe0804160825s6dfc942eja5a4c6acc495d819@mail.gmail.com> References: <810a540e0804160135l6dcf6fd6s13784c110a969f69@mail.gmail.com> <57c63afe0804160530u73675e04r915445f49ccbb4d9@mail.gmail.com> <70F45E06-6BEF-4123-9673-35334E95F5BF@gmail.com> <57c63afe0804160825s6dfc942eja5a4c6acc495d819@mail.gmail.com> Message-ID: On 16 Apr 2008, at 16:25, David Chelimsky wrote: > First - it is entirely possible that I have no local record of the > missing commits, since I pulled from a repo that has no record of > them. So does this mean that a pull from git actually removes commits? That doesn't seem to make sense -- but I guess if the commits were undone (with a reset say) then a pull might remove them? One theory: It's possible that Pat rebased a branch, which means that the commit numbers will all change (I think) - he could have potentially have rebased the wrong way round, which means that all the commits have been removed from master and replayed onto a topic branch. He may not have pushed this yet, in which case the commits vanished from the master branch the next time he pushed up....? Is this plausible? Chris From pergesu at gmail.com Wed Apr 16 12:44:44 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 16 Apr 2008 09:44:44 -0700 Subject: [rspec-devel] Has anyone pulled from the repo recently, but not on/after 4/16? Message-ID: <810a540e0804160944l2e954e25sd9ae0cb088138760@mail.gmail.com> I screwed up the repo on github and a bunch of commits are missing. So I'm hoping that there are a couple people out there that have pulled fairly recently (ideally on 4/15), but not today. If so, can you please tar up your entire rspec-dev project and email it to me so I can try to fix this? Please do NOT update your repo to get the latest changes at this point. Pat From pergesu at gmail.com Wed Apr 16 15:23:16 2008 From: pergesu at gmail.com (Pat Maddox) Date: Wed, 16 Apr 2008 12:23:16 -0700 Subject: [rspec-devel] Has anyone pulled from the repo recently, but not on/after 4/16? In-Reply-To: <810a540e0804160944l2e954e25sd9ae0cb088138760@mail.gmail.com> References: <810a540e0804160944l2e954e25sd9ae0cb088138760@mail.gmail.com> Message-ID: <810a540e0804161223k3045b6b1w30c5f191d6829a9a@mail.gmail.com> Actually, if you updated the repo after 4/16, please send it to me. Also include any winning lotto numbers for the date of your last pull. In fact, screw the repo, I just want the lotto numbers. From chris at edendevelopment.co.uk Wed Apr 16 15:59:55 2008 From: chris at edendevelopment.co.uk (Chris Parsons) Date: Wed, 16 Apr 2008 20:59:55 +0100 Subject: [rspec-devel] [rspec-users] Has anyone pulled from the repo recently, but not on/after 4/16? In-Reply-To: <810a540e0804160944l2e954e25sd9ae0cb088138760@mail.gmail.com> References: <810a540e0804160944l2e954e25sd9ae0cb088138760@mail.gmail.com> Message-ID: Hi Pat, On 16 Apr 2008, at 17:44, Pat Maddox wrote: > I screwed up the repo on github and a bunch of commits are missing. > So I'm hoping that there are a couple people out there that have > pulled fairly recently (ideally on 4/15), but not today. If so, can > you please tar up your entire rspec-dev project and email it to me so > I can try to fix this? Can't help with a repo, sorry... but have a couple of ideas: * It's worth keeping a backup of the broken repo on your machine. That way we can do a postmortem and attempt work out what on earth happened to those commits. * Can anyone remember any of the text of the commit messages? If I'm right and a rebase rewrote the commit numbers then it's possible that they might be sitting as dangling commits inside your repository, under different commit numbers. A git fsck might find those if you try it on your repo and examine each dangling commit in turn. HTH, -Chris From dchelimsky at gmail.com Wed Apr 16 22:39:39 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 16 Apr 2008 22:39:39 -0400 Subject: [rspec-devel] rspec + github == !submodules Message-ID: <57c63afe0804161939k12ce1652x2b5fe7d79be2d47a@mail.gmail.com> Hey all, We ran into some problems last night with the repos up at github. We initially thought it was a git-submodules bug. We learned that it was something else, but in the process of trying to find the source of the bug, we learned a few things about git-submodules and have decided that it creates an unfortunate set of complications and dependencies for a development effort like ours. To that end, we have simplified. No more submodules. To update, do the following: cd rspec-dev git pull rake git:update See http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches for more info. Cheers, David From bryansray at gmail.com Wed Apr 16 22:58:45 2008 From: bryansray at gmail.com (Bryan Ray) Date: Wed, 16 Apr 2008 21:58:45 -0500 Subject: [rspec-devel] rspec + github == !submodules In-Reply-To: <57c63afe0804161939k12ce1652x2b5fe7d79be2d47a@mail.gmail.com> References: <57c63afe0804161939k12ce1652x2b5fe7d79be2d47a@mail.gmail.com> Message-ID: <29a0119e0804161958m39f6b69dp128df055bc9463cc@mail.gmail.com> Good job on all the research guys. I know it must have been frustrating, but glad you got it figured out. On Wed, Apr 16, 2008 at 9:39 PM, David Chelimsky wrote: > Hey all, > > We ran into some problems last night with the repos up at github. We > initially thought it was a git-submodules bug. We learned that it was > something else, but in the process of trying to find the source of the > bug, we learned a few things about git-submodules and have decided > that it creates an unfortunate set of complications and dependencies > for a development effort like ours. > > To that end, we have simplified. No more submodules. To update, do the > following: > > cd rspec-dev > git pull > rake git:update > > See http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches > for more info. > > Cheers, > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > -- Bryan Ray http://www.bryanray.net "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080416/391babd5/attachment.html From chris at edendevelopment.co.uk Thu Apr 17 17:18:24 2008 From: chris at edendevelopment.co.uk (Chris Parsons) Date: Thu, 17 Apr 2008 22:18:24 +0100 Subject: [rspec-devel] Is the pre_commit passing? In-Reply-To: <57c63afe0804160352u7dae86dhe6092b38c0175285@mail.gmail.com> References: <1d7ddd110804152153r1cdc6bd2ndf7d24fd98a13d63@mail.gmail.com> <7C9EC498-FF3B-433C-A3A4-4680710F9ED8@gmail.com> <57c63afe0804160352u7dae86dhe6092b38c0175285@mail.gmail.com> Message-ID: <64CB5E0D-243A-4D86-9F29-1255AED88586@edendevelopment.co.uk> On 16 Apr 2008, at 11:52, David Chelimsky wrote: >> On Wed, Apr 9, 2008 at 1:48 PM, David Chelimsky >> >> wrote: >> >> The pre_commit is not working correctly right now. We're working >> on it though. >> [snip] > It should be working right now. There are a couple of things that are > commented that I have to address, but you should be able to run it. I've just done a clean clone from the github repo and am trying to get pre_commit passing. I've followed the instructions carefully on http://github.com/dchelimsky/rspec-dev/wikis/contributingpatches and am getting an odd error (trace copied at bottom of email). Is this a good time to be getting a local dev environment up and running, or are you guys still working on the repo? Also, if I've got some coding time to burn, is there a particular priority order of tickets that I should work on in lighthouse? Thanks Chris Trace from pre_commit: ** Invoke spec_html (first_time) ** Execute spec_html /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/rspec/lib/ spec/runner/formatter/base_text_formatter.rb:17:in `initialize': No such file or directory - ../../../../doc/output/report.html (Errno::ENOENT) from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/formatter/base_text_formatter.rb:17:in `open' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/formatter/base_text_formatter.rb:17:in `initialize' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/formatter/html_formatter.rb:11:in `initialize' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/options.rb:173:in `new' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/options.rb:173:in `load_formatters' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/options.rb:166:in `map' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/options.rb:166:in `load_formatters' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/options.rb:157:in `formatters' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/reporter.rb:70:in `formatters' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/reporter.rb:57:in `dump' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/example_group_runner.rb:37:in `finish' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/example_group_runner.rb:26:in `run' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/options.rb:94:in `run_examples' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/lib/spec/runner/command_line.rb:19:in `run' from /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/ rspec/bin/spec:4 rake aborted! Command ruby -I"/Users/chris/src/rspec-dev/example_rails_app/vendor/ plugins/rspec/lib" "/Users/chris/src/rspec-dev/example_rails_app/ vendor/plugins/rspec/bin/spec" "spec/autotest/discover_spec.rb" "spec/ autotest/rspec_spec.rb" "spec/spec/example/configuration_spec.rb" "spec/spec/example/example_group/described_module_spec.rb" "spec/spec/ example/example_group/warning_messages_spec.rb" "spec/spec/example/ example_group_class_definition_spec.rb" "spec/spec/example/ example_group_factory_spec.rb" "spec/spec/example/ example_group_methods_spec.rb" "spec/spec/example/ example_group_spec.rb" "spec/spec/example/example_matcher_spec.rb" "spec/spec/example/example_methods_spec.rb" "spec/spec/example/ example_runner_spec.rb" "spec/spec/example/example_spec.rb" "spec/spec/ example/nested_example_group_spec.rb" "spec/spec/example/ pending_module_spec.rb" "spec/spec/example/predicate_matcher_spec.rb" "spec/spec/example/shared_example_group_spec.rb" "spec/spec/example/ subclassing_example_group_spec.rb" "spec/spec/expectations/differs/ default_spec.rb" "spec/spec/expectations/extensions/object_spec.rb" "spec/spec/expectations/fail_with_spec.rb" "spec/spec/extensions/ main_spec.rb" "spec/spec/interop/test/unit/spec_spec.rb" "spec/spec/ interop/test/unit/testcase_spec.rb" "spec/spec/interop/test/unit/ testsuite_adapter_spec.rb" "spec/spec/matchers/be_close_spec.rb" "spec/ spec/matchers/be_spec.rb" "spec/spec/matchers/change_spec.rb" "spec/ spec/matchers/description_generation_spec.rb" "spec/spec/matchers/ eql_spec.rb" "spec/spec/matchers/equal_spec.rb" "spec/spec/matchers/ exist_spec.rb" "spec/spec/matchers/handler_spec.rb" "spec/spec/ matchers/has_spec.rb" "spec/spec/matchers/have_spec.rb" "spec/spec/ matchers/include_spec.rb" "spec/spec/matchers/match_spec.rb" "spec/ spec/matchers/matcher_methods_spec.rb" "spec/spec/matchers/ mock_constraint_matchers_spec.rb" "spec/spec/matchers/ operator_matcher_spec.rb" "spec/spec/matchers/raise_error_spec.rb" "spec/spec/matchers/respond_to_spec.rb" "spec/spec/matchers/ satisfy_spec.rb" "spec/spec/matchers/simple_matcher_spec.rb" "spec/ spec/matchers/throw_symbol_spec.rb" "spec/spec/mocks/ any_number_of_times_spec.rb" "spec/spec/mocks/ argument_expectation_spec.rb" "spec/spec/mocks/at_least_spec.rb" "spec/ spec/mocks/at_most_spec.rb" "spec/spec/mocks/bug_report_10260_spec.rb" "spec/spec/mocks/bug_report_10263_spec.rb" "spec/spec/mocks/ bug_report_11545_spec.rb" "spec/spec/mocks/bug_report_15719_spec.rb" "spec/spec/mocks/bug_report_7611_spec.rb" "spec/spec/mocks/ bug_report_7805_spec.rb" "spec/spec/mocks/bug_report_8165_spec.rb" "spec/spec/mocks/bug_report_8302_spec.rb" "spec/spec/mocks/ failing_mock_argument_constraints_spec.rb" "spec/spec/mocks/ hash_including_matcher_spec.rb" "spec/spec/mocks/ mock_ordering_spec.rb" "spec/spec/mocks/mock_space_spec.rb" "spec/spec/ mocks/mock_spec.rb" "spec/spec/mocks/multiple_return_value_spec.rb" "spec/spec/mocks/null_object_mock_spec.rb" "spec/spec/mocks/ once_counts_spec.rb" "spec/spec/mocks/options_hash_spec.rb" "spec/spec/ mocks/partial_mock_spec.rb" "spec/spec/mocks/ partial_mock_using_mocks_directly_spec.rb" "spec/spec/mocks/ passing_mock_argument_constraints_spec.rb" "spec/spec/mocks/ precise_counts_spec.rb" "spec/spec/mocks/record_messages_spec.rb" "spec/spec/mocks/stub_spec.rb" "spec/spec/mocks/twice_counts_spec.rb" "spec/spec/package/bin_spec_spec.rb" "spec/spec/runner/ class_and_argument_parser_spec.rb" "spec/spec/runner/ command_line_spec.rb" "spec/spec/runner/drb_command_line_spec.rb" "spec/spec/runner/execution_context_spec.rb" "spec/spec/runner/ formatter/failing_example_groups_formatter_spec.rb" "spec/spec/runner/ formatter/failing_examples_formatter_spec.rb" "spec/spec/runner/ formatter/html_formatter_spec.rb" "spec/spec/runner/formatter/ profile_formatter_spec.rb" "spec/spec/runner/formatter/ progress_bar_formatter_spec.rb" "spec/spec/runner/formatter/ snippet_extractor_spec.rb" "spec/spec/runner/formatter/ spec_mate_formatter_spec.rb" "spec/spec/runner/formatter/ specdoc_formatter_spec.rb" "spec/spec/runner/formatter/story/ html_formatter_spec.rb" "spec/spec/runner/formatter/story/ plain_text_formatter_spec.rb" "spec/spec/runner/heckle_runner_spec.rb" "spec/spec/runner/heckler_spec.rb" "spec/spec/runner/ noisy_backtrace_tweaker_spec.rb" "spec/spec/runner/ option_parser_spec.rb" "spec/spec/runner/options_spec.rb" "spec/spec/ runner/output_one_time_spec.rb" "spec/spec/runner/ quiet_backtrace_tweaker_spec.rb" "spec/spec/runner/reporter_spec.rb" "spec/spec/runner/resources/a_spec.rb" "spec/spec/runner/ spec_parser_spec.rb" "spec/spec/runner_spec.rb" "spec/spec/story/ extensions/main_spec.rb" "spec/spec/story/extensions_spec.rb" "spec/ spec/story/given_scenario_spec.rb" "spec/spec/story/runner/ plain_text_story_runner_spec.rb" "spec/spec/story/runner/ scenario_collector_spec.rb" "spec/spec/story/runner/ scenario_runner_spec.rb" "spec/spec/story/runner/ story_mediator_spec.rb" "spec/spec/story/runner/story_parser_spec.rb" "spec/spec/story/runner/story_runner_spec.rb" "spec/spec/story/ runner_spec.rb" "spec/spec/story/scenario_spec.rb" "spec/spec/story/ step_group_spec.rb" "spec/spec/story/step_mother_spec.rb" "spec/spec/ story/step_spec.rb" "spec/spec/story/story_spec.rb" "spec/spec/story/ world_spec.rb" "spec/spec/translator_spec.rb" --format html:../../../../doc/output/report.html --backtrace failed ./lib/spec/rake/spectask.rb:184:in `define' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1003:in `verbose' ./lib/spec/rake/spectask.rb:153:in `define' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `call' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `execute' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `execute' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `synchronize' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in `invoke' /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/rspec/ pre_commit/lib/pre_commit/pre_commit.rb:9:in `rake_invoke' /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/rspec/ pre_commit/lib/pre_commit/core.rb:10:in `website' /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/rspec/ pre_commit/lib/pre_commit/core.rb:4:in `pre_commit' /Users/chris/src/rspec-dev/example_rails_app/vendor/plugins/rspec/ rakefile:162 /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `call' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:546:in `execute' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:541:in `execute' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:508:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `synchronize' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:501:in `invoke_with_call_chain' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:494:in `invoke' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1931:in `invoke_task' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `each' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1909:in `top_level' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1903:in `top_level' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1881:in `run' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1948:in `standard_exception_handling' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/lib/rake.rb:1878:in `run' /Library/Ruby/Gems/1.8/gems/rake-0.8.1/bin/rake:31 /usr/bin/rake:19:in `load' /usr/bin/rake:19 rake aborted! RSpec Core pre_commit failed /Users/chris/src/rspec-dev/rakefile:24 (See full trace by running task with --trace) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080417/f805590f/attachment-0001.html From pergesu at gmail.com Fri Apr 18 18:27:14 2008 From: pergesu at gmail.com (Pat Maddox) Date: Fri, 18 Apr 2008 18:27:14 -0400 Subject: [rspec-devel] Back to one repository? Message-ID: <810a540e0804181527o2b7d300dgbaf8340d049b8abd@mail.gmail.com> Brian, Alex Chaffee and I were talking about the repository layout just now. Alex pointed out that there's a lot of overhead when using the rspec project... I've written a bunch of rake tasks to reduce that, but even with those there's overhead. And as we figure out more tasks, we'll have to write more rake tasks to automate some of the stuff. For example, if you git:pull and there's a conflict, you have to go resolve the conflict and continue the rebase. Does it make sense to write a git:continue command that will examine any repos that had a conflict and are in need of a rebase continue? I'm not sure at this point, but it's one of many potential questions. Alex suggested that we go back to one repository, and change the plugin installation process. Basically the only reason the repos are split right now is because there's no way to check out directories, and we want people to easily install the rspec and rspec-rails plugins. What if instead of separate repos, we had people put the entire codebase under vendor/rspec? Then they could run a script like vendor/rspec/install_plugins that would export the rspec and rspec-rails dirs to vendor/plugins. I realize there will probably be some apprehension given that David did a lot of work to split the repos in the first place, and the headaches over the past couple days, but I think it's a very good idea that's worth considering. If nothing else, we should keep it in mind over the next couple weeks, and see what growing pains we experience that might be avoided by a unified repo. Pat From dchelimsky at gmail.com Fri Apr 18 21:05:31 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 18 Apr 2008 21:05:31 -0400 Subject: [rspec-devel] Back to one repository? In-Reply-To: <810a540e0804181527o2b7d300dgbaf8340d049b8abd@mail.gmail.com> References: <810a540e0804181527o2b7d300dgbaf8340d049b8abd@mail.gmail.com> Message-ID: <57c63afe0804181805y4f90e9aeo9c886cd079f7f8c2@mail.gmail.com> On Fri, Apr 18, 2008 at 6:27 PM, Pat Maddox wrote: > Brian, Alex Chaffee and I were talking about the repository layout > just now. Alex pointed out that there's a lot of overhead when using > the rspec project... I've written a bunch of rake tasks to reduce > that, but even with those there's overhead. And as we figure out more > tasks, we'll have to write more rake tasks to automate some of the > stuff. For example, if you git:pull and there's a conflict, you have > to go resolve the conflict and continue the rebase. Does it make > sense to write a git:continue command that will examine any repos that > had a conflict and are in need of a rebase continue? I'm not sure at > this point, but it's one of many potential questions. > > Alex suggested that we go back to one repository, and change the > plugin installation process. Basically the only reason the repos are > split right now is because there's no way to check out directories, > and we want people to easily install the rspec and rspec-rails > plugins. > > What if instead of separate repos, we had people put the entire > codebase under vendor/rspec? Then they could run a script like > vendor/rspec/install_plugins that would export the rspec and > rspec-rails dirs to vendor/plugins. > > I realize there will probably be some apprehension given that David > did a lot of work to split the repos in the first place, and the > headaches over the past couple days, but I think it's a very good idea > that's worth considering. If nothing else, we should keep it in mind > over the next couple weeks, and see what growing pains we experience > that might be avoided by a unified repo. The work that I've done (and that you've done, Pat) should not be a consideration. If there is a better way, we should pursue it. I have a lot of thoughts about this but no time to present them right now. I'll follow up over the weekend. David From jake.howerton at gmail.com Sat Apr 19 02:01:50 2008 From: jake.howerton at gmail.com (Jake Howerton) Date: Sat, 19 Apr 2008 02:01:50 -0400 Subject: [rspec-devel] Back to one repository? In-Reply-To: <57c63afe0804181805y4f90e9aeo9c886cd079f7f8c2@mail.gmail.com> References: <810a540e0804181527o2b7d300dgbaf8340d049b8abd@mail.gmail.com> <57c63afe0804181805y4f90e9aeo9c886cd079f7f8c2@mail.gmail.com> Message-ID: <218a05e40804182301i674c2824i6c0b454ee0b97a7c@mail.gmail.com> Thought I could chime in on how I am managing embedded repositories on git right now. I mentioned braid before and this is the main tool I am using. I have 2 projects that share some code that I keep in a 'shared' repo. If the project necessitates that changes be made to the shared code I make the changes in my branch of the current project, finish my changes, and merge that branch into master for that project. I then generate a patch for the shared lib and apply it to that repo. Here is how the flow might look if you are working on rspec this way: Say you have ~/rspec-work and rspec-dev, rspec, and rspec-rails repos are below this. I am going to assume braid is setup to track everything for the time being. You would do your work in rspec-dev. cd ~/rspec-work/rspec-dev git checkout -b new-feature .... do work and find it necessary to change shared dir ... run pre_commit and merge your changes into master # generate a patch to go to rspec repo git braid-diff lib/rspec > ~/rspec-work/rspec/my-change.patch cd ~/rspec-work/rspec patch -p3 < my-change.patch (not sure what the p level would actually be) rm my-change.patch git commit -a -m 'commit new feature from rspec-dev' Then push changes in rspec to github, switch back to rspec-dev and update your braid/track branch, rinse, repeat. braid-diff is an alias I have: braid-diff = diff braid/track master -- I don't know if this seems convoluted but it is really simple once you make it a habit and it could probably be a little more automated. -Jake On Fri, Apr 18, 2008 at 9:05 PM, David Chelimsky wrote: > > On Fri, Apr 18, 2008 at 6:27 PM, Pat Maddox wrote: > > Brian, Alex Chaffee and I were talking about the repository layout > > just now. Alex pointed out that there's a lot of overhead when using > > the rspec project... I've written a bunch of rake tasks to reduce > > that, but even with those there's overhead. And as we figure out more > > tasks, we'll have to write more rake tasks to automate some of the > > stuff. For example, if you git:pull and there's a conflict, you have > > to go resolve the conflict and continue the rebase. Does it make > > sense to write a git:continue command that will examine any repos that > > had a conflict and are in need of a rebase continue? I'm not sure at > > this point, but it's one of many potential questions. > > > > Alex suggested that we go back to one repository, and change the > > plugin installation process. Basically the only reason the repos are > > split right now is because there's no way to check out directories, > > and we want people to easily install the rspec and rspec-rails > > plugins. > > > > What if instead of separate repos, we had people put the entire > > codebase under vendor/rspec? Then they could run a script like > > vendor/rspec/install_plugins that would export the rspec and > > rspec-rails dirs to vendor/plugins. > > > > I realize there will probably be some apprehension given that David > > did a lot of work to split the repos in the first place, and the > > headaches over the past couple days, but I think it's a very good idea > > that's worth considering. If nothing else, we should keep it in mind > > over the next couple weeks, and see what growing pains we experience > > that might be avoided by a unified repo. > > The work that I've done (and that you've done, Pat) should not be a > consideration. If there is a better way, we should pursue it. > > I have a lot of thoughts about this but no time to present them right > now. I'll follow up over the weekend. > > David > > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Sat Apr 19 04:59:51 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 19 Apr 2008 04:59:51 -0400 Subject: [rspec-devel] Back to one repository? In-Reply-To: <810a540e0804181527o2b7d300dgbaf8340d049b8abd@mail.gmail.com> References: <810a540e0804181527o2b7d300dgbaf8340d049b8abd@mail.gmail.com> Message-ID: On Apr 18, 2008, at 6:27 PM, Pat Maddox wrote: > Brian, Alex Chaffee and I were talking about the repository layout > just now. Alex pointed out that there's a lot of overhead when using > the rspec project... Alex and I had an interesting conversation about this last summer at the Agile conference. My recollection is that, at that time, his primary concerns were about the object structure and life-cycle - that it was difficult to understand when things went wrong or how to extend it. I think we addressed a lot of his concerns with the major refactoring effort that Brian and Aslak undertook last fall, but there is certainly more work to do. I'll follow up on some thoughts about that in a separate thread. The point is that my experience thus far is that if Alex is having trouble with something, it's probably because it's a serious pain in the ass :) > I've written a bunch of rake tasks to reduce > that, but even with those there's overhead. And as we figure out more > tasks, we'll have to write more rake tasks to automate some of the > stuff. Excellent point. Clearly this is an unfortunate maintenance burden. > For example, if you git:pull and there's a conflict, you have > to go resolve the conflict and continue the rebase. Does it make > sense to write a git:continue command that will examine any repos that > had a conflict and are in need of a rebase continue? I'm not sure at > this point, but it's one of many potential questions. > > Alex suggested that we go back to one repository, and change the > plugin installation process. Basically the only reason the repos are > split right now is because there's no way to check out directories, > and we want people to easily install the rspec and rspec-rails > plugins. That's not the only reason. With one repo and the rspec and rspec- rails directory up at the root level, developing rspec-rails is a PITA. We had rake tasks that copied those two directories down to the example rails app. I had tried to make that work w/ symlinks but found that the generators did not work when I did that. Not sure if that's a rails issue or an rspec issue, but either way it is an unresolved issue. When we had the rspec_on_rails repo only available down below the rails app we got a number of complaints of the low visibility. People wanted to grab http://svn.rubyforge.org/rspec/rspec_on_rails instead of http://svn.rubyforge.org/rspec/example_rails_app/vendor/plugins/rspec_on_rails . With the repos separated out, the rspec and rspec-rails repos have high visibility, are conceptually decoupled, AND can just be installed where they need to be for development. These are the pros that must be weighed against the cons of developers/contributors having to managing multiple repos. We also need to consider the Ruby developer who doesn't use rails. We'd be forcing that user to clone a bunch of stuff they don't need. I'm not sure how important an issue that is when weighed against everything else, but it is certainly a consideration. > What if instead of separate repos, we had people put the entire > codebase under vendor/rspec? Then they could run a script like > vendor/rspec/install_plugins that would export the rspec and > rspec-rails dirs to vendor/plugins. > > I realize there will probably be some apprehension given that David > did a lot of work to split the repos in the first place, Not relevant. > and the > headaches over the past couple days, but I think it's a very good idea > that's worth considering. Agree. > If nothing else, we should keep it in mind > over the next couple weeks, and see what growing pains we experience > that might be avoided by a unified repo. I agree we should keep an eye on this. I have a lot of reservations, but remain open to the discussion. Another consideration is that separating them out has the effect, IMO, of reducing the binding of rspec to rails development. There is a world of users who believe that rspec is a rails development tool. While I'm proud of the fact that rspec-rails has become a serious player in the rails space, I'm also excited to see it being used in other contexts. A shining example, even though they're not using our rspec library (for good reason - it uses advanced language features that are not available in the early phases of the development of a language implementation) is rubinius. What they are doing with rspec is absolutely astounding. Keeping rspec core as a separate repo increases the likelihood of more exciting developments like this outside the rails space. So there are a lot of things to consider here. Looking forward to hearing more thoughts on this. Cheers, David > Pat From matt-lists at reprocessed.org Fri Apr 25 09:36:50 2008 From: matt-lists at reprocessed.org (Matt Patterson) Date: Fri, 25 Apr 2008 14:36:50 +0100 Subject: [rspec-devel] DRb Runner is melting my brain Message-ID: <86728142-E85D-4316-AE55-EEFABFE3DDE8@reprocessed.org> I'm working on some stuff for #373 (http://is.gd/5uA), and it was all going swimmingly until I started messing around with Options. I'm trying to refactor the example group collection stuff out into a separate Collector, which works fine until you try and use a global rspec_collector (ala rspec_options) - The DRb specs (presumably the first one) goes into some kind of infinite loop and exhausts all memory. Would someone be willing to explain how the DRb runner and its specs work? Thanks, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From matt-lists at reprocessed.org Fri Apr 25 10:53:24 2008 From: matt-lists at reprocessed.org (Matt Patterson) Date: Fri, 25 Apr 2008 15:53:24 +0100 Subject: [rspec-devel] DRb Runner is melting my brain In-Reply-To: <86728142-E85D-4316-AE55-EEFABFE3DDE8@reprocessed.org> References: <86728142-E85D-4316-AE55-EEFABFE3DDE8@reprocessed.org> Message-ID: <4194B05A-3C39-4A28-BAB3-2ABADDC39BA7@reprocessed.org> On 25 Apr 2008, at 14:36, Matt Patterson wrote: > I'm working on some stuff for #373 (http://is.gd/5uA), and it was > all going swimmingly until I started messing around with Options. > > I'm trying to refactor the example group collection stuff out into a > separate Collector, which works fine until you try and use a global > rspec_collector (ala rspec_options) - The DRb specs (presumably the > first one) goes into some kind of infinite loop and exhausts all > memory. > > Would someone be willing to explain how the DRb runner and its specs > work? Scratch that, it wasn't the DRb runner, just the normal Spec::Runner::CommandLine specs. Brain still melting, but a little less is oozing from my ears. Thanks for your continued indulgence, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From matt-lists at reprocessed.org Tue Apr 29 08:52:18 2008 From: matt-lists at reprocessed.org (Matt Patterson) Date: Tue, 29 Apr 2008 13:52:18 +0100 Subject: [rspec-devel] rspec_options / Spec::Story::Runner.run_options Message-ID: <3F250162-C495-4B16-B670-AA956C1DCCC0@reprocessed.org> I've done some work around refactoring and reworking the rspec_options mechanism, for http://rspec.lighthouseapp.com/projects/5645/tickets/373-spec-story-runner-run_options-and-rspec_options-code-duplication-and-problems . I thought it might be worth talking through what I've done and why... I was originally looking to try and figure out how to solve the problem of Spec::Story::Runner.run_options getting nothing from ARGV if you required 'spec/rails/story_adapter'. The problem was easy to solve - just comment out the body of run_options and, basically, make it delegate to rspec_options. Unfortunately, that caused lots of spec failures that I couldn't wrap my head around... Anyway, my observation was that things were hard to understand because of the rspec_options juggling you needed to do to spec rspec... I thought I'd have a look at finding a way to attack some of that, and the ticket above, and the commit at http://github.com/fidothe/rspec/commit/71b03ed9dd9aa07aba24a94ee495d0adc00cdb3c is my attempt at that. My first thought was that rspec_options performed two main, and distinct, tasks - collecting example groups to be run, and parsing the options given so the examples can be run. Collecting example groups is essentially done as a side effect when classes containing examples are defined. As far as I could tell, splitting out spec collection would be enough to stop rspec_options getting called during the intial "require 'spec'" stage, and that seemed like a win too. My next thought was that it would be great if the monkeying you need to do in order to spec out rspec itself could be made simpler and more explicit. I hope that what I've strikes people as a step towards that - I think it's got potential. I introduced Spec::Collector, the class, and Spec.collector, the global accessor, in order to allow spec collection to be split out. Using Spec.collector makes it really easy to stub out the collector for specs involving it - like a lot of the example_group_methods specs. I added a chunk of rewritten specs in spec/spec/example/ example_group_methods_spec.rb which demonstrate that. The before and after :all blocks are there to allow side-by-side testing with the existing rspec_options based stuff (as are the conditionals in the code itself). I think that the resulting specs are a lot clearer - all the monkeying is much more explicit, a lot of which is because of being able to use mocks and stubs easily (I assume you could mock or stub rspec_options, but you'd have to do something like rely on self- as-implicit-receiver) The same approach could easily be applied to rspec_options itself. Any thoughts? Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/