From dchelimsky at gmail.com Thu Oct 2 23:52:51 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 2 Oct 2008 22:52:51 -0500 Subject: [rspec-devel] [ANN] RSpec-1.1.7 is released Message-ID: <57c63afe0810022052k529b84bid56bc50c6417097d@mail.gmail.com> The RSpec Development is happy to announce the release of rspec-1.1.7 and rspec-rails-1.1.7 This is recommended for anyone who upgraded to 1.1.5 earlier this week as it addresses bugs that were introduced by that release: == rspec and rspec-rails 1.1.7 * fixed dependency problem introduced in rspec-rails-1.1.6 earlier this evening :( == rspec-1.1.6 * 2 bug fixes * fixed bug where negative message expectations following stubs resulted in false (negative) positives. Fixes #548. * fixed bug where Not Yet Implemented examples report incorrect caller. Fixes #547. * 1 minor enhancement * removed deprecated mock argument constraint symbols == rspec-rails-1.1.6 * 1 bug fix * fixed regression where values assigned to the assigns hash were not accessible from the example. Fixes #549. == More Information http://rspec.info/ http://github.com/dchelimsky/rspec/wikis http://rspec.lighthouseapp.com/ From dchelimsky at gmail.com Fri Oct 3 09:14:22 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 3 Oct 2008 08:14:22 -0500 Subject: [rspec-devel] [ANN] RSpec-1.1.8 Message-ID: <57c63afe0810030614u6e245034u51e86ba644630112@mail.gmail.com> Thanks to some very quick feedback on the 1.1.7 release, the RSpec Development Team is proud to announce yet another bug fix release: RSpec-1.1.8. RSpec-1.1.8 includes the following changes: == rspec-1.1.8 * 2 bug fixes * restore colorized output in linux and windows w/ autotest (Tim Pope). Fixes #413. * autospec no longer hangs on windows. Fixes #554. == rspec-rails-1.1.8 * 2 bug fixes * correctly handle assigns that are false. Fixes #552. * ensure that NotYetImplemented examples report as pending (fixed in rspec, not rspec-rails). Fixes #553. == Install [sudo] gem install rspec [sudo] gem install rspec-rails == More information http://rspec.info http://rubyforge.org/projects/rspec/ http://github.com/dchelimsky/rspec/wikis http://rspec.lighthouseapp.com/ From antti.tarvainen at iki.fi Sun Oct 5 05:23:32 2008 From: antti.tarvainen at iki.fi (Antti Tarvainen) Date: Sun, 5 Oct 2008 12:23:32 +0300 Subject: [rspec-devel] Proposal: when_it syntax Message-ID: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> Hello. I propose a new syntax that helps DRY up specs when using one-expectation-per-example style. There have been similar proposals before, but no patches. As far as I know, the idea wasn't killed, just forgotten. The patch adds a new "when_it" method and a new parameter to the "it" method. "When_it" describes the action of the example, allowing "it" parts to describe only the expectation. The new parameter to "it" is called :implicitly, and it means that the expectation should be run before the "when_it" part. (That is, it is a mock expectation, and regards the implicit interface of the object.) "It" parts without the :implicitly parameter are run after the "when_it" part. Here's an example of the syntax: describe Controller do before(:each) do @model = mock("model").as_null_object @view = mock("view").as_null_object @controller = Controller.new(@model, @view) end when_it do @return_value = @controller.act_on(:some_input) end it "should get data from model", :implicitly do @model.should_receive(:data_for).with(:some_input) end it "should return :success" do @return_value.should == :success end end For a slightly longer example, see http://tinyurl.com/when-it-example . What do you think? The new syntax makes specs more DRY, but does it improve readability? [patch] http://github.com/tarvaina/rspec/commits/topic/when_it_in_one_commit http://github.com/tarvaina/rspec-rails/commits/topic/when_it_compatibility [one expectation per example] http://techblog.daveastels.com/2006/08/27/one-expectation-per-example-a-remake-of-one-assertion-per-test/ [old discussions] http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10285&atid=3152 http://rubyforge.org/pipermail/rspec-users/2007-April/001386.html Antti From zach.dennis at gmail.com Sun Oct 5 10:54:31 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Sun, 5 Oct 2008 10:54:31 -0400 Subject: [rspec-devel] Proposal: when_it syntax In-Reply-To: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> References: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> Message-ID: <85d99afe0810050754x43c1d83sd713e7af2175bdf6@mail.gmail.com> On Sun, Oct 5, 2008 at 5:23 AM, Antti Tarvainen wrote: > Hello. > > > I propose a new syntax that helps DRY up specs when using > one-expectation-per-example style. There have been similar proposals > before, but no patches. As far as I know, the idea wasn't killed, just > forgotten. > > The patch adds a new "when_it" method and a new parameter to the "it" > method. "When_it" describes the action of the example, allowing "it" > parts to describe only the expectation. > > The new parameter to "it" is called :implicitly, and it means that the > expectation should be run before the "when_it" part. (That is, it is a > mock expectation, and regards the implicit interface of the object.) > "It" parts without the :implicitly parameter are run after the > "when_it" part. > > > Here's an example of the syntax: > > describe Controller do > before(:each) do > @model = mock("model").as_null_object > @view = mock("view").as_null_object > @controller = Controller.new(@model, @view) > end > > when_it do > @return_value = @controller.act_on(:some_input) > end > > it "should get data from model", :implicitly do > @model.should_receive(:data_for).with(:some_input) > end > > it "should return :success" do > @return_value.should == :success > end > end > > > For a slightly longer example, see http://tinyurl.com/when-it-example . > > What do you think? The new syntax makes specs more DRY, but does it > improve readability? > I don't think it does. Here's why IMO: * "when_it do" reads horribly. Just read it outloud, it sounds wrong. * The word :implicitly that may get appended is a noise word. It is not apparent what it does, and it cannot be inferred. It must be learned. It also provides no value (outside of technical detail) to a reader of the example that body of the it block will be used before making the method call, or after making the method call. * Using :implicitly means the body of an it block does one of two things. For developers this means that they must always keep the context of how the it block will be run when reading the example, or writing new ones. * when_it can't be used across the board, and nor should it, because it separates the call to execute the behaviour from any important pre-conditions and also any post behaviour verification. These things should be tightly bound together to make the example clear and understandable to readers of the code. When I say pre-conditions I'm not just talking about what goes in a before block. I'm talking about communicating to the reader so they don't have to go scrolling up to a before block (let alone up through several before blocks). For instance: it "finds the most recent project by year" do Project.should_receive(:project_by_year).with("1999") get :show, :year => "1999" end it "assigns :project" do Project.stub!(:project_by_year).and_return "project" get :show assigns[:project].should == "project" end Even if a before block stubbed out Project.project_by_year to return a project, in the assigns example, I want to explicitly tell the reader of the example what it is being assigned to. It doesn't appear that you can do this "assigns" example with when_it. -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From zach.dennis at gmail.com Sun Oct 5 11:00:37 2008 From: zach.dennis at gmail.com (Zach Dennis) Date: Sun, 5 Oct 2008 11:00:37 -0400 Subject: [rspec-devel] Proposal: when_it syntax In-Reply-To: <85d99afe0810050754x43c1d83sd713e7af2175bdf6@mail.gmail.com> References: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> <85d99afe0810050754x43c1d83sd713e7af2175bdf6@mail.gmail.com> Message-ID: <85d99afe0810050800r3286eac9y2d5ad2bbac8f03f1@mail.gmail.com> I forgot to ask. Have you been using when_it yourself? What experience have you had with it? Zach On Sun, Oct 5, 2008 at 10:54 AM, Zach Dennis wrote: > On Sun, Oct 5, 2008 at 5:23 AM, Antti Tarvainen wrote: >> Hello. >> >> >> I propose a new syntax that helps DRY up specs when using >> one-expectation-per-example style. There have been similar proposals >> before, but no patches. As far as I know, the idea wasn't killed, just >> forgotten. >> >> The patch adds a new "when_it" method and a new parameter to the "it" >> method. "When_it" describes the action of the example, allowing "it" >> parts to describe only the expectation. >> >> The new parameter to "it" is called :implicitly, and it means that the >> expectation should be run before the "when_it" part. (That is, it is a >> mock expectation, and regards the implicit interface of the object.) >> "It" parts without the :implicitly parameter are run after the >> "when_it" part. >> >> >> Here's an example of the syntax: >> >> describe Controller do >> before(:each) do >> @model = mock("model").as_null_object >> @view = mock("view").as_null_object >> @controller = Controller.new(@model, @view) >> end >> >> when_it do >> @return_value = @controller.act_on(:some_input) >> end >> >> it "should get data from model", :implicitly do >> @model.should_receive(:data_for).with(:some_input) >> end >> >> it "should return :success" do >> @return_value.should == :success >> end >> end >> >> >> For a slightly longer example, see http://tinyurl.com/when-it-example . >> >> What do you think? The new syntax makes specs more DRY, but does it >> improve readability? >> > > I don't think it does. Here's why IMO: > > * "when_it do" reads horribly. Just read it outloud, it sounds wrong. > * The word :implicitly that may get appended is a noise word. It is > not apparent what it does, and it cannot be inferred. It must be > learned. It also provides no value (outside of technical detail) to a > reader of the example that body of the it block will be used before > making the method call, or after making the method call. > * Using :implicitly means the body of an it block does one of two > things. For developers this means that they must always keep the > context of how the it block will be run when reading the example, or > writing new ones. > * when_it can't be used across the board, and nor should it, because > it separates the call to execute the behaviour from any important > pre-conditions and also any post behaviour verification. These things > should be tightly bound together to make the example clear and > understandable to readers of the code. > > When I say pre-conditions I'm not just talking about what goes in a > before block. I'm talking about communicating to the reader so they > don't have to go scrolling up to a before block (let alone up through > several before blocks). For instance: > > it "finds the most recent project by year" do > Project.should_receive(:project_by_year).with("1999") > get :show, :year => "1999" > end > > it "assigns :project" do > Project.stub!(:project_by_year).and_return "project" > get :show > assigns[:project].should == "project" > end > > Even if a before block stubbed out Project.project_by_year to return a > project, in the assigns example, I want to explicitly tell the reader > of the example what it is being assigned to. It doesn't appear that > you can do this "assigns" example with when_it. > > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com From dchelimsky at gmail.com Sun Oct 5 11:10:48 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Sun, 5 Oct 2008 10:10:48 -0500 Subject: [rspec-devel] Proposal: when_it syntax In-Reply-To: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> References: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> Message-ID: <57c63afe0810050810l27380b62yc098f8df0fc403d4@mail.gmail.com> On Sun, Oct 5, 2008 at 4:23 AM, Antti Tarvainen wrote: > Hello. > > > I propose a new syntax that helps DRY up specs when using > one-expectation-per-example style. There have been similar proposals > before, but no patches. As far as I know, the idea wasn't killed, just > forgotten. > > The patch adds a new "when_it" method and a new parameter to the "it" > method. "When_it" describes the action of the example, allowing "it" > parts to describe only the expectation. > > The new parameter to "it" is called :implicitly, and it means that the > expectation should be run before the "when_it" part. (That is, it is a > mock expectation, and regards the implicit interface of the object.) > "It" parts without the :implicitly parameter are run after the > "when_it" part. > > > Here's an example of the syntax: > > describe Controller do > before(:each) do > @model = mock("model").as_null_object > @view = mock("view").as_null_object > @controller = Controller.new(@model, @view) > end > > when_it do > @return_value = @controller.act_on(:some_input) > end > > it "should get data from model", :implicitly do > @model.should_receive(:data_for).with(:some_input) > end > > it "should return :success" do > @return_value.should == :success > end > end > > > For a slightly longer example, see http://tinyurl.com/when-it-example . > > What do you think? The new syntax makes specs more DRY, but does it > improve readability? To be honest, I think this really hurts readability. First, :implicitly doesn't really say what it means, which is "the implicit action should happen after the code in this block". Second, the fact that the action happens before some actions in the group and after others is going to be confusing when trying to understand a failure. Ironically, Yehuda Katz is in the middle of working on a patch that supports something very similar, though it doesn't handle the before/after action choice: http://gist.github.com/14670 Here's what I'm thinking. Rather than loading up rspec with new stuff like this that I'm personally skeptical about, what I'd rather do is expose a legitimate extension point that would allow you to do exactly what you're trying to do and the same for yehuda. Something like this: Spec::Runner.configure do |config| config.extend_example do |example| # access to a wrapper for the example # that exposes its args hash and other # useful stuff end config.extend_example_group do |group| # access to a wrapper for the example group # that exposes its args hash and other # useful stuff end end Then you could (theoretically) do stuff like this: GIVENS = {} def given(name, &block) GIVENS[name] = block end given "logged in" do login end Spec::Runner.configure do |config| config.extend_example do |example| if example.args[:given] example.before &GIVENS[args[:given]] end end end That's a quick and dirty implementation (and may or may not work as written ;) ), but just to show you the sort of power you'd have. Maybe there's a better way, but WDYT, in general, about the idea of having some sort of official extension points for Examples and ExampleGroups that would make it easy for people to write (and publish) their own extensions without fear of rspec breaking them later? David > > > [patch] > http://github.com/tarvaina/rspec/commits/topic/when_it_in_one_commit > http://github.com/tarvaina/rspec-rails/commits/topic/when_it_compatibility > > [one expectation per example] > http://techblog.daveastels.com/2006/08/27/one-expectation-per-example-a-remake-of-one-assertion-per-test/ > > [old discussions] > http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10285&atid=3152 > http://rubyforge.org/pipermail/rspec-users/2007-April/001386.html > > > Antti > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sun Oct 5 12:55:40 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 5 Oct 2008 18:55:40 +0200 Subject: [rspec-devel] Cucumber 0.1.7 released Message-ID: <8d961d900810050955x1f302c8aj307a5032bb259e98@mail.gmail.com> I just released 0.1.7 as a gem. (As usual, it will take a few hours before it rsyncs around the world). Changes are here: http://github.com/aslakhellesoy/cucumber/tree/v0.1.7/History.txt Thanks to everyone who's contributed with feedback and patches! Cheers, Aslak From aslak.hellesoy at gmail.com Mon Oct 6 20:58:12 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 7 Oct 2008 02:58:12 +0200 Subject: [rspec-devel] Proposal: when_it syntax In-Reply-To: <57c63afe0810050810l27380b62yc098f8df0fc403d4@mail.gmail.com> References: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> <57c63afe0810050810l27380b62yc098f8df0fc403d4@mail.gmail.com> Message-ID: <8d961d900810061758i5087eb05ge18d03f74e721996@mail.gmail.com> On Sun, Oct 5, 2008 at 5:10 PM, David Chelimsky wrote: > On Sun, Oct 5, 2008 at 4:23 AM, Antti Tarvainen wrote: >> Hello. >> >> >> I propose a new syntax that helps DRY up specs when using >> one-expectation-per-example style. There have been similar proposals >> before, but no patches. As far as I know, the idea wasn't killed, just >> forgotten. >> >> The patch adds a new "when_it" method and a new parameter to the "it" >> method. "When_it" describes the action of the example, allowing "it" >> parts to describe only the expectation. >> >> The new parameter to "it" is called :implicitly, and it means that the >> expectation should be run before the "when_it" part. (That is, it is a >> mock expectation, and regards the implicit interface of the object.) >> "It" parts without the :implicitly parameter are run after the >> "when_it" part. >> >> >> Here's an example of the syntax: >> >> describe Controller do >> before(:each) do >> @model = mock("model").as_null_object >> @view = mock("view").as_null_object >> @controller = Controller.new(@model, @view) >> end >> >> when_it do >> @return_value = @controller.act_on(:some_input) >> end >> >> it "should get data from model", :implicitly do >> @model.should_receive(:data_for).with(:some_input) >> end >> >> it "should return :success" do >> @return_value.should == :success >> end >> end >> >> >> For a slightly longer example, see http://tinyurl.com/when-it-example . >> >> What do you think? The new syntax makes specs more DRY, but does it >> improve readability? > > To be honest, I think this really hurts readability. First, > :implicitly doesn't really say what it means, which is "the implicit > action should happen after the code in this block". > > Second, the fact that the action happens before some actions in the > group and after others is going to be confusing when trying to > understand a failure. > > Ironically, Yehuda Katz is in the middle of working on a patch that > supports something very similar, though it doesn't handle the > before/after action choice: http://gist.github.com/14670 > > Here's what I'm thinking. Rather than loading up rspec with new stuff > like this that I'm personally skeptical about, what I'd rather do is > expose a legitimate extension point that would allow you to do exactly > what you're trying to do and the same for yehuda. Something like this: > > Spec::Runner.configure do |config| > config.extend_example do |example| > # access to a wrapper for the example > # that exposes its args hash and other > # useful stuff > end > > config.extend_example_group do |group| > # access to a wrapper for the example group > # that exposes its args hash and other > # useful stuff > end > end > > Then you could (theoretically) do stuff like this: > > GIVENS = {} > > def given(name, &block) > GIVENS[name] = block > end > > given "logged in" do > login > end > > Spec::Runner.configure do |config| > config.extend_example do |example| > if example.args[:given] > example.before &GIVENS[args[:given]] > end > end > end > > That's a quick and dirty implementation (and may or may not work as > written ;) ), but just to show you the sort of power you'd have. > > Maybe there's a better way, but WDYT, in general, about the idea of > having some sort of official extension points for Examples and > ExampleGroups that would make it easy for people to write (and > publish) their own extensions without fear of rspec breaking them > later? > I'm probably missing something here, but it seems to me that Antti and Yehuda's examples can be simply written with #before or regular method defs: http://gist.github.com/15198 (Yehuda's original is http://gist.github.com/14670) http://gist.github.com/15199 (Antti's original higher up in this thread) While I agree we need a better extension API, I don't see why it's needed in the cases presented here. Too much magic - we already have simpler constructs to do the same. Aslak > David > >> >> >> [patch] >> http://github.com/tarvaina/rspec/commits/topic/when_it_in_one_commit >> http://github.com/tarvaina/rspec-rails/commits/topic/when_it_compatibility >> >> [one expectation per example] >> http://techblog.daveastels.com/2006/08/27/one-expectation-per-example-a-remake-of-one-assertion-per-test/ >> >> [old discussions] >> http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10285&atid=3152 >> http://rubyforge.org/pipermail/rspec-users/2007-April/001386.html >> >> >> Antti >> _______________________________________________ >> 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 wycats at gmail.com Mon Oct 6 21:06:10 2008 From: wycats at gmail.com (Yehuda Katz) Date: Mon, 6 Oct 2008 18:06:10 -0700 Subject: [rspec-devel] Proposal: when_it syntax In-Reply-To: <8d961d900810061758i5087eb05ge18d03f74e721996@mail.gmail.com> References: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> <57c63afe0810050810l27380b62yc098f8df0fc403d4@mail.gmail.com> <8d961d900810061758i5087eb05ge18d03f74e721996@mail.gmail.com> Message-ID: <245fb4700810061806u247528v40202338f0346654@mail.gmail.com> My goal here is to try to get people comfortable with black-box testing. Unfortunately, every fewer ounce of syntactic sugar is an impediment to convincing people to do the right thing. This is somewhat similar, imho, to the argument about test/unit syntax vs. rspec syntax. Is foo.should == bar really much better than assert_equal(foo, bar)? And think about the magic required to implement it! -- Yehuda On Mon, Oct 6, 2008 at 5:58 PM, aslak hellesoy wrote: > On Sun, Oct 5, 2008 at 5:10 PM, David Chelimsky > wrote: > > On Sun, Oct 5, 2008 at 4:23 AM, Antti Tarvainen > wrote: > >> Hello. > >> > >> > >> I propose a new syntax that helps DRY up specs when using > >> one-expectation-per-example style. There have been similar proposals > >> before, but no patches. As far as I know, the idea wasn't killed, just > >> forgotten. > >> > >> The patch adds a new "when_it" method and a new parameter to the "it" > >> method. "When_it" describes the action of the example, allowing "it" > >> parts to describe only the expectation. > >> > >> The new parameter to "it" is called :implicitly, and it means that the > >> expectation should be run before the "when_it" part. (That is, it is a > >> mock expectation, and regards the implicit interface of the object.) > >> "It" parts without the :implicitly parameter are run after the > >> "when_it" part. > >> > >> > >> Here's an example of the syntax: > >> > >> describe Controller do > >> before(:each) do > >> @model = mock("model").as_null_object > >> @view = mock("view").as_null_object > >> @controller = Controller.new(@model, @view) > >> end > >> > >> when_it do > >> @return_value = @controller.act_on(:some_input) > >> end > >> > >> it "should get data from model", :implicitly do > >> @model.should_receive(:data_for).with(:some_input) > >> end > >> > >> it "should return :success" do > >> @return_value.should == :success > >> end > >> end > >> > >> > >> For a slightly longer example, see http://tinyurl.com/when-it-example . > >> > >> What do you think? The new syntax makes specs more DRY, but does it > >> improve readability? > > > > To be honest, I think this really hurts readability. First, > > :implicitly doesn't really say what it means, which is "the implicit > > action should happen after the code in this block". > > > > Second, the fact that the action happens before some actions in the > > group and after others is going to be confusing when trying to > > understand a failure. > > > > Ironically, Yehuda Katz is in the middle of working on a patch that > > supports something very similar, though it doesn't handle the > > before/after action choice: http://gist.github.com/14670 > > > > Here's what I'm thinking. Rather than loading up rspec with new stuff > > like this that I'm personally skeptical about, what I'd rather do is > > expose a legitimate extension point that would allow you to do exactly > > what you're trying to do and the same for yehuda. Something like this: > > > > Spec::Runner.configure do |config| > > config.extend_example do |example| > > # access to a wrapper for the example > > # that exposes its args hash and other > > # useful stuff > > end > > > > config.extend_example_group do |group| > > # access to a wrapper for the example group > > # that exposes its args hash and other > > # useful stuff > > end > > end > > > > Then you could (theoretically) do stuff like this: > > > > GIVENS = {} > > > > def given(name, &block) > > GIVENS[name] = block > > end > > > > given "logged in" do > > login > > end > > > > Spec::Runner.configure do |config| > > config.extend_example do |example| > > if example.args[:given] > > example.before &GIVENS[args[:given]] > > end > > end > > end > > > > That's a quick and dirty implementation (and may or may not work as > > written ;) ), but just to show you the sort of power you'd have. > > > > Maybe there's a better way, but WDYT, in general, about the idea of > > having some sort of official extension points for Examples and > > ExampleGroups that would make it easy for people to write (and > > publish) their own extensions without fear of rspec breaking them > > later? > > > > I'm probably missing something here, but it seems to me that Antti and > Yehuda's examples can be simply written with #before or regular method > defs: > > http://gist.github.com/15198 (Yehuda's original is > http://gist.github.com/14670) > http://gist.github.com/15199 (Antti's original higher up in this thread) > > While I agree we need a better extension API, I don't see why it's > needed in the cases presented here. Too much magic - we already have > simpler constructs to do the same. > > Aslak > > > David > > > >> > >> > >> [patch] > >> http://github.com/tarvaina/rspec/commits/topic/when_it_in_one_commit > >> > http://github.com/tarvaina/rspec-rails/commits/topic/when_it_compatibility > >> > >> [one expectation per example] > >> > http://techblog.daveastels.com/2006/08/27/one-expectation-per-example-a-remake-of-one-assertion-per-test/ > >> > >> [old discussions] > >> > http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10285&atid=3152 > >> http://rubyforge.org/pipermail/rspec-users/2007-April/001386.html > >> > >> > >> Antti > >> _______________________________________________ > >> 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 > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at mattwynne.net Sun Oct 5 16:37:55 2008 From: matt at mattwynne.net (Matt Wynne) Date: Sun, 5 Oct 2008 21:37:55 +0100 Subject: [rspec-devel] [rspec-users] Cucumber 0.1.7 released In-Reply-To: <8d961d900810050955x1f302c8aj307a5032bb259e98@mail.gmail.com> References: <8d961d900810050955x1f302c8aj307a5032bb259e98@mail.gmail.com> Message-ID: Shame we didn't see you at Citcon, Aslak, but I'm glad to hear you were doing something useful instead! Looking forward to playing with the new toys. cheers, Matt On 5 Oct 2008, at 17:55, aslak hellesoy wrote: > I just released 0.1.7 as a gem. (As usual, it will take a few hours > before it rsyncs around the world). > > Changes are here: > http://github.com/aslakhellesoy/cucumber/tree/v0.1.7/History.txt > > Thanks to everyone who's contributed with feedback and patches! > > Cheers, > Aslak > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users From antti.tarvainen at iki.fi Tue Oct 7 12:06:05 2008 From: antti.tarvainen at iki.fi (Antti Tarvainen) Date: Tue, 7 Oct 2008 19:06:05 +0300 Subject: [rspec-devel] Proposal: when_it syntax In-Reply-To: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> References: <5b89e3bd0810050223s4c8e7dfby4d59e1d366eaadbb@mail.gmail.com> Message-ID: <5b89e3bd0810070906t58f812d0r711da50fa0d5fcf3@mail.gmail.com> > I propose a new syntax that helps DRY up specs when using > one-expectation-per-example style. There have been similar proposals > before, but no patches. As far as I know, the idea wasn't killed, just > forgotten. Thanks for the feedback, everyone. I added the ability for when_it to accept descriptions, so you can write: describe PoemsController do when_it "responds to GET index" do get :index end # ... end (See http://gist.github.com/15300 for the entire file.) - David: I agree that hunting the causes of fails will be more difficult with this syntax. It may be easier to keep the spec up to date though through refactorings. It's the same old battle between readability and DRY. - David and Zach, regarding the names "when_it" and ":implicitly": I like "when_it", since it describes the intention well, especially with the desciptions as in the above example. ":Implicitly" I don't like, but I couldn't think of a better word. - Zach: Yes, at least for description blocks with lots of examples, it is less confusing to write preconditions in a single example. - Zach: I haven't tried this in any real project yet. I intend to do that in a small internal project. - Aslak: You are right. All this does is remove the :act method call from the examples. - David: I think extension API is a good idea. Would rspec-rails use it? I agree with you that "when_it" should probably not be added to RSpec, at least not now. Antti From lianliming at gmail.com Thu Oct 9 12:01:23 2008 From: lianliming at gmail.com (Lian Liming) Date: Fri, 10 Oct 2008 00:01:23 +0800 Subject: [rspec-devel] New spoken language support for cucumber Message-ID: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> Hi all, I still haven't found any documentation on how to add a new spoken language support to cucumber. I have tried following two steps to add a new one. 1) Add a new section to the languange.yaml and identify the translations of the keywords. 2) run rake -f gem_tasks/treetop.rake treetop:compile The new language I am trying to add is my mother tongue -- Chinese. By applying above steps, it basically works. The only thing I have to deal with is that, there is no space between keyword and rest of the sentence in Chinese language. That is also the important difference between Asian languages(including Chinese, Japanese, Korea) and western languages (those have been supported in cucumber). Take a look at following example: In English: Given I have entered 50 into the calculator In Chinese: ?????????????50 To support native Chinese conventions, I have to change the treetop rules a little bit as following: ---- diff -------- 34c34 < scenario_keyword space? name:line_to_eol steps:(space step_sequence)? { --- > scenario_keyword space name:line_to_eol steps:(space step_sequence)? { 99c99 < given_scenario_keyword space? name:line_to_eol { --- > given_scenario_keyword space name:line_to_eol { 108c108 < step_keyword space? name:line_to_eol { --- > step_keyword space name:line_to_eol { ---- end of diff -------- This change targets Asian languages and I don't know whether it breaks the conventions of western languages. I also would like to know if there is any more flexible solution of supporting different kinds of spoken languages. Any ideas? Liming From mailing_lists at railsnewbie.com Thu Oct 9 23:37:51 2008 From: mailing_lists at railsnewbie.com (Scott Taylor) Date: Thu, 9 Oct 2008 23:37:51 -0400 Subject: [rspec-devel] Parameterized shared examples Message-ID: <7137211F-7AF5-4DD9-9E84-CEC327BB1E92@railsnewbie.com> Implementation issues aside, there was once some talk about shared behaviors which could be passed parameters. I talked to David about this a while back, and he told me to hold off on it (this was a few months ago). It hasn't yet been implemented. Should I give it a shot? Any advice? Scott From tastapod at gmail.com Fri Oct 10 04:56:49 2008 From: tastapod at gmail.com (Dan North) Date: Fri, 10 Oct 2008 09:56:49 +0100 Subject: [rspec-devel] New spoken language support for cucumber In-Reply-To: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> References: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> Message-ID: A few years ago the Thai government sponsored a fork of Firefox to support the Thai language. The Firefox core team felt the changes necessary to support Thai would be disproportionate relative to the user base so they didn't want to have the changes in the core. Because they are using distributed SCM they have found it is easy to keep the two forks in sync and share common bug fixes and enhancements. If the changes required for Chinese language support are straightforward I suggest we adopt them into the mainline, otherwise we could have a similar collaborative model where there are different "flavours" of cucumber based on the various regional language rules. wdyt? Dan 2008/10/9 Lian Liming > Hi all, > > I still haven't found any documentation on how to add a new spoken > language support to cucumber. I have tried following two steps to add > a new one. > > 1) Add a new section to the languange.yaml and identify the > translations of the keywords. > 2) run rake -f gem_tasks/treetop.rake treetop:compile > > The new language I am trying to add is my mother tongue -- Chinese. By > applying above steps, it basically works. The only thing I have to > deal with is that, there is no space between keyword and rest of the > sentence in Chinese language. That is also the important difference > between Asian languages(including Chinese, Japanese, Korea) and > western languages (those have been supported in cucumber). > > Take a look at following example: > > In English: Given I have entered 50 into the calculator > In Chinese: ?????????????50 > > To support native Chinese conventions, I have to change the treetop > rules a little bit as following: > > ---- diff -------- > 34c34 > < scenario_keyword space? name:line_to_eol steps:(space step_sequence)? > { > --- > > scenario_keyword space name:line_to_eol steps:(space step_sequence)? > { > 99c99 > < given_scenario_keyword space? name:line_to_eol { > --- > > given_scenario_keyword space name:line_to_eol { > 108c108 > < step_keyword space? name:line_to_eol { > --- > > step_keyword space name:line_to_eol { > ---- end of diff -------- > > This change targets Asian languages and I don't know whether it breaks > the conventions of western languages. I also would like to know if > there is any more flexible solution of supporting different kinds of > spoken languages. Any ideas? > > Liming > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From aslak.hellesoy at gmail.com Fri Oct 10 05:45:19 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 10 Oct 2008 11:45:19 +0200 Subject: [rspec-devel] New spoken language support for cucumber In-Reply-To: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> References: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> Message-ID: <8d961d900810100245p28d69cfav4cf5fb61d672854c@mail.gmail.com> On Thu, Oct 9, 2008 at 6:01 PM, Lian Liming wrote: > Hi all, > > I still haven't found any documentation on how to add a new spoken > language support to cucumber. I have tried following two steps to add > a new one. > > 1) Add a new section to the languange.yaml and identify the > translations of the keywords. > 2) run rake -f gem_tasks/treetop.rake treetop:compile > Congrats you found out :-) The rake bit is actually a bit easier: rake treetop:compile > The new language I am trying to add is my mother tongue -- Chinese. By > applying above steps, it basically works. The only thing I have to > deal with is that, there is no space between keyword and rest of the > sentence in Chinese language. That is also the important difference > between Asian languages(including Chinese, Japanese, Korea) and > western languages (those have been supported in cucumber). > > Take a look at following example: > > In English: Given I have entered 50 into the calculator > In Chinese: ?????????????50 > > To support native Chinese conventions, I have to change the treetop > rules a little bit as following: > > ---- diff -------- > 34c34 > < scenario_keyword space? name:line_to_eol steps:(space step_sequence)? { > --- >> scenario_keyword space name:line_to_eol steps:(space step_sequence)? { > 99c99 > < given_scenario_keyword space? name:line_to_eol { > --- >> given_scenario_keyword space name:line_to_eol { > 108c108 > < step_keyword space? name:line_to_eol { > --- >> step_keyword space name:line_to_eol { > ---- end of diff -------- > > This change targets Asian languages and I don't know whether it breaks > the conventions of western languages. I also would like to know if You could have found out by running: rake treetop:compile spec Works fine it seems! I've just committed it: http://github.com/aslakhellesoy/cucumber/commits/master > there is any more flexible solution of supporting different kinds of > spoken languages. Any ideas? > I think it's easy enough - especially now that I've documented it a little: http://github.com/aslakhellesoy/cucumber/wikis/spoken-languages I'm really excited to see support for Chinese and other Asian languages! I'm looking forward to pulling in your translation, Liming :-) Aslak > Liming > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From aslak.hellesoy at gmail.com Fri Oct 10 05:45:54 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Fri, 10 Oct 2008 11:45:54 +0200 Subject: [rspec-devel] New spoken language support for cucumber In-Reply-To: References: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> Message-ID: <8d961d900810100245n42aca306u643a651a8baa547a@mail.gmail.com> On Fri, Oct 10, 2008 at 10:56 AM, Dan North wrote: > A few years ago the Thai government sponsored a fork of Firefox to support > the Thai language. The Firefox core team felt the changes necessary to > support Thai would be disproportionate relative to the user base so they > didn't want to have the changes in the core. Because they are using > distributed SCM they have found it is easy to keep the two forks in sync and > share common bug fixes and enhancements. > > If the changes required for Chinese language support are straightforward I > suggest we adopt them into the mainline, otherwise we could have a similar > collaborative model where there are different "flavours" of cucumber based > on the various regional language rules. > No special plan seems necessary. > wdyt? > Dan > > > 2008/10/9 Lian Liming >> >> Hi all, >> >> I still haven't found any documentation on how to add a new spoken >> language support to cucumber. I have tried following two steps to add >> a new one. >> >> 1) Add a new section to the languange.yaml and identify the >> translations of the keywords. >> 2) run rake -f gem_tasks/treetop.rake treetop:compile >> >> The new language I am trying to add is my mother tongue -- Chinese. By >> applying above steps, it basically works. The only thing I have to >> deal with is that, there is no space between keyword and rest of the >> sentence in Chinese language. That is also the important difference >> between Asian languages(including Chinese, Japanese, Korea) and >> western languages (those have been supported in cucumber). >> >> Take a look at following example: >> >> In English: Given I have entered 50 into the calculator >> In Chinese: ?????????????50 >> >> To support native Chinese conventions, I have to change the treetop >> rules a little bit as following: >> >> ---- diff -------- >> 34c34 >> < scenario_keyword space? name:line_to_eol steps:(space >> step_sequence)? { >> --- >> > scenario_keyword space name:line_to_eol steps:(space step_sequence)? >> > { >> 99c99 >> < given_scenario_keyword space? name:line_to_eol { >> --- >> > given_scenario_keyword space name:line_to_eol { >> 108c108 >> < step_keyword space? name:line_to_eol { >> --- >> > step_keyword space name:line_to_eol { >> ---- end of diff -------- >> >> This change targets Asian languages and I don't know whether it breaks >> the conventions of western languages. I also would like to know if >> there is any more flexible solution of supporting different kinds of >> spoken languages. Any ideas? >> >> Liming >> _______________________________________________ >> 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 tastapod at gmail.com Fri Oct 10 08:08:30 2008 From: tastapod at gmail.com (Dan North) Date: Fri, 10 Oct 2008 13:08:30 +0100 Subject: [rspec-devel] New spoken language support for cucumber In-Reply-To: <8d961d900810100245n42aca306u643a651a8baa547a@mail.gmail.com> References: <2ab0f52d0810090901w3b7efe12yf2eb160472e3b61c@mail.gmail.com> <8d961d900810100245n42aca306u643a651a8baa547a@mail.gmail.com> Message-ID: Excellent :) 2008/10/10 aslak hellesoy > On Fri, Oct 10, 2008 at 10:56 AM, Dan North wrote: > > A few years ago the Thai government sponsored a fork of Firefox to > support > > the Thai language. The Firefox core team felt the changes necessary to > > support Thai would be disproportionate relative to the user base so they > > didn't want to have the changes in the core. Because they are using > > distributed SCM they have found it is easy to keep the two forks in sync > and > > share common bug fixes and enhancements. > > > > If the changes required for Chinese language support are straightforward > I > > suggest we adopt them into the mainline, otherwise we could have a > similar > > collaborative model where there are different "flavours" of cucumber > based > > on the various regional language rules. > > > > No special plan seems necessary. > > > wdyt? > > Dan > > > > > > 2008/10/9 Lian Liming > >> > >> Hi all, > >> > >> I still haven't found any documentation on how to add a new spoken > >> language support to cucumber. I have tried following two steps to add > >> a new one. > >> > >> 1) Add a new section to the languange.yaml and identify the > >> translations of the keywords. > >> 2) run rake -f gem_tasks/treetop.rake treetop:compile > >> > >> The new language I am trying to add is my mother tongue -- Chinese. By > >> applying above steps, it basically works. The only thing I have to > >> deal with is that, there is no space between keyword and rest of the > >> sentence in Chinese language. That is also the important difference > >> between Asian languages(including Chinese, Japanese, Korea) and > >> western languages (those have been supported in cucumber). > >> > >> Take a look at following example: > >> > >> In English: Given I have entered 50 into the calculator > >> In Chinese: ?????????????50 > >> > >> To support native Chinese conventions, I have to change the treetop > >> rules a little bit as following: > >> > >> ---- diff -------- > >> 34c34 > >> < scenario_keyword space? name:line_to_eol steps:(space > >> step_sequence)? { > >> --- > >> > scenario_keyword space name:line_to_eol steps:(space > step_sequence)? > >> > { > >> 99c99 > >> < given_scenario_keyword space? name:line_to_eol { > >> --- > >> > given_scenario_keyword space name:line_to_eol { > >> 108c108 > >> < step_keyword space? name:line_to_eol { > >> --- > >> > step_keyword space name:line_to_eol { > >> ---- end of diff -------- > >> > >> This change targets Asian languages and I don't know whether it breaks > >> the conventions of western languages. I also would like to know if > >> there is any more flexible solution of supporting different kinds of > >> spoken languages. Any ideas? > >> > >> Liming > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan-ml at dan42.com Fri Oct 10 10:16:03 2008 From: dan-ml at dan42.com (Daniel DeLorme) Date: Fri, 10 Oct 2008 23:16:03 +0900 Subject: [rspec-devel] ruby1.9 constant lookup rules Message-ID: <48EF63A3.2080200@dan42.com> So I was trying to make rspec work with ruby1.9. The first bugs I got when running "rake spec" were not difficult to fix: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/437 But after that it gets a little more complicated. Constant lookup rules have changed in 1.9; basically they are no longer lexically scoped. This means an instance_eval changes the lookup path of a given constant. Like this: def describe(&block) instance_eval(&block) end module Foo Bar = 42 def self.bar describe do puts Bar end end end Foo.bar => NameError: uninitialized constant Module::Bar Because rspec uses instance_eval for the "describe" blocks, this is a problem. And it's not really something that a simple patch can fix, this is more of a design issue IMHO. I could imagine patching this with some const_missing magic, but I think that would be going against the grain of ruby1.9. You could also change all constant names to be fully qualified (as in the patch I attached to this mail) but that is really ugly. This blog post by _why seems to have come just in time: http://hackety.org/2008/10/06/mixingOurWayOutOfInstanceEval.html That seems like a good alternative to instance_eval; after all we don't really want to evaluate the block in a completely different context; we just want to have a few extra methods available inside it. But this is not a decision that a rspec newbie like me can make. -- Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: fully-qualified-constants.patch Type: text/x-diff Size: 9502 bytes Desc: not available URL: From dchelimsky at gmail.com Fri Oct 10 11:37:11 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 10 Oct 2008 10:37:11 -0500 Subject: [rspec-devel] ruby1.9 constant lookup rules In-Reply-To: <48EF63A3.2080200@dan42.com> References: <48EF63A3.2080200@dan42.com> Message-ID: <57c63afe0810100837q668de6adm1bf9c55d8afe4d12@mail.gmail.com> On Fri, Oct 10, 2008 at 9:16 AM, Daniel DeLorme wrote: > So I was trying to make rspec work with ruby1.9. The first bugs I got when > running "rake spec" were not difficult to fix: > http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/437 > > But after that it gets a little more complicated. Constant lookup rules have > changed in 1.9; basically they are no longer lexically scoped. This means an > instance_eval changes the lookup path of a given constant. Like this: > > def describe(&block) > instance_eval(&block) > end > module Foo > Bar = 42 > def self.bar > describe do > puts Bar > end > end > end > Foo.bar > => NameError: uninitialized constant Module::Bar > > Because rspec uses instance_eval for the "describe" blocks, this is a > problem. And it's not really something that a simple patch can fix, this is > more of a design issue IMHO. I could imagine patching this with some > const_missing magic, but I think that would be going against the grain of > ruby1.9. You could also change all constant names to be fully qualified (as > in the patch I attached to this mail) but that is really ugly. > > This blog post by _why seems to have come just in time: > http://hackety.org/2008/10/06/mixingOurWayOutOfInstanceEval.html > That seems like a good alternative to instance_eval; after all we don't > really want to evaluate the block in a completely different context; we just > want to have a few extra methods available inside it. > > But this is not a decision that a rspec newbie like me can make. Hey Daniel, Thanks for the effort. Would you kindly post this to http://rspec.lighthouseapp.com? Cheers, David > > -- > Daniel > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From george at benevolentcode.com Tue Oct 14 12:31:57 2008 From: george at benevolentcode.com (George Anderson) Date: Tue, 14 Oct 2008 12:31:57 -0400 Subject: [rspec-devel] protocol for patching rspec-tmbundle Message-ID: <782d66f30810140931j26e6eef5r94dd003aaed352fc@mail.gmail.com> Hi, I have installed the latest rspec-tmbundle (from git://github.com/dchelimsky/rspec-tmbundle.git). I was getting some funky error with the "Alternate File" command when the target file didn't exist. It would just display a path-related error and not prompt me to create the missing file. I tracked the issue down to my having a space in ENV['TM_SUPPORT_PATH'] which caused SwitchCommand#create? to choke. Being a decent person, I wanted to BDD the fix, but I don't know how best to spec system calls, and the existing specs seem to not cover the code I needed to patch. The fix was simple enough: diff --git a/Support/lib/spec/mate/switch_command.rb b/Support/lib/spec/mate/switch_command.rb index 22868f0..7b8f8d8 100644 --- a/Support/lib/spec/mate/switch_command.rb +++ b/Support/lib/spec/mate/switch_command.rb @@ -69,7 +69,7 @@ module Spec end def create?(relative_twin, file_type) - answer = `#{ ENV['TM_SUPPORT_PATH'] }/bin/CocoaDialog.app/Contents/MacOS/CocoaDialog yesno-msgbox --no-cancel --icon document --informative-text "#{relative_twin}" --text "Create missing #{file_type}?"` + answer = `'#{ ENV['TM_SUPPORT_PATH'] }/bin/CocoaDialog.app/Contents/MacOS/CocoaDialog' yesno-msgbox --no-cancel --icon document --informative-text "#{relative_twin}" --text "Create missing #{file_type}?"` answer.to_s.chomp == "1" end which just wraps: #{ ENV['TM_SUPPORT_PATH'] }/bin/CocoaDialog.app/Contents/MacOS/CocoaDialog in single quotes. With this patch, the "Alternate File" command was working as expected. However, when it created the new file, it did so outside of the context of my TextMate project. So I patched SwitchCommand#write_and_open. Once again, I'm at a loss for creating specs for the code I was touching and existing specs didn't cover it. It is a very simple fix: diff --git a/Support/lib/spec/mate/switch_command.rb b/Support/lib/spec/mate/switch_command.rb index 7b8f8d8..7ada2fa 100644 --- a/Support/lib/spec/mate/switch_command.rb +++ b/Support/lib/spec/mate/switch_command.rb @@ -123,8 +123,7 @@ SPEC def write_and_open(path, content) `mkdir -p "#{File.dirname(path)}"` `touch "#{path}"` - `osascript &>/dev/null -e 'tell app "SystemUIServer" to activate' -e 'tell app "TextMate" to activate'` - `"$TM_SUPPORT_PATH/bin/mate" "#{path}"` + `osascript &>/dev/null -e 'tell app "SystemUIServer" to activate' -e 'tell app "TextMate" to activate' -e 'tell app "TextMate" to open #{path}'` escaped_content = content.gsub("\n","\\n").gsub('$','\\$').gsub('"','\\\\\\\\\\\\"') `osascript &>/dev/null -e "tell app \\"TextMate\\" to insert \\"#{escaped_content}\\" as snippet true"` end With this patch, the new file will be created within the context of the open TextMate project. How do I go about getting these patches accepted? Admittedly I have no specs to prove my changes, which poses a significant barrier to acceptance, I assume. Should I open a Lighthouse ticket and attach the patches? Can someone guide me on how to create specs for my changes? Any advice would be greatly appreciated. Thanks, /g -- George Anderson BenevolentCode LLC O: (410) 461-7553 C: (410) 218-5185 george at benevolentcode.com From dchelimsky at gmail.com Tue Oct 21 01:14:11 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Oct 2008 00:14:11 -0500 Subject: [rspec-devel] [ANN] rspec 1.1.9 Released Message-ID: <57c63afe0810202214w3c163bercf78c55f81e78aa2@mail.gmail.com> rspec version 1.1.9 has been released! * Behaviour Driven Development for Ruby. Changes: ### Version 1.1.9 / 2008-10-20 WARNING: This release removes implicit inclusion of modules in example groups. This means that if you have 'describe MyModule do', MyModule will not be included in the group. * 2 major enhancements * Add extend to configuration (thanks to advice from Chad Fowler) * Modules are no longer implicitly included in example groups * 4 minor enhancements * mingw indicates windows too (thanks to Luis Lavena for the tip) * improved output for partial mock expecation failures * it_should_behave_like now accepts n names of shared groups * eliminated redundant inclusion/extension of ExampleGroupMethods * 6 bug fixes * spec command with no arguments prints help * fixed typo in help. Fixes #73. * fixed bug where should_receive..and_yield after similar stub added the args_to_yield to the stub's original args_to_yield (Pat Maddox) * fixed bug where rspec-autotest (autospec) was loading non-spec files in spec directory. Fixes #559. * fixed bug where should_not_receive was reporting twice * fixed bug where rspec tries to run examples just because it is required (even if there are no examples loaded). Fixes #575. * From dchelimsky at gmail.com Tue Oct 21 01:14:44 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Oct 2008 00:14:44 -0500 Subject: [rspec-devel] [ANN] rspec-rails 1.1.9 Released Message-ID: <57c63afe0810202214w72c43cfetbb016150d0c2987c@mail.gmail.com> rspec-rails version 1.1.9 has been released! * Behaviour Driven Development for Ruby on Rails. Changes: ### Version 1.1.9 / 2008-10-20 * 4 bug fixes * require 'rubygems' in script/spec * fix failure message for error_on and errors_on (Patch from Mike Vincent). Fixes #566. * fix issues that arise in view spec if passing actual template name to render (Patch from Mike Vincent). Fixes #551. * fixed bug accessing assigns from helper examples * From dchelimsky at gmail.com Tue Oct 21 14:51:42 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 21 Oct 2008 13:51:42 -0500 Subject: [rspec-devel] config.gem/rspec-rails/rspec bug (#577) Message-ID: <57c63afe0810211151v72f432cbo63e1d59abd8c2442@mail.gmail.com> Hey all, Just a heads up about a bug related to configuring the rspec gems in your rails 2.1.1 projects: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/577 Apparently, if you config.gem both rspec and rspec-rails 1.1.9 w/ rspec first, you'll get an error: # DON'T DO THIS: config.gem 'rspec', :lib => 'spec', :version => '1.1.9' config.gem 'rspec-rails', :lib => 'spec/rails', :version => '1.1.9' The workaround is to either reverse these lines: # OK config.gem 'rspec-rails', :lib => 'spec/rails', :version => '1.1.9' config.gem 'rspec', :lib => 'spec', :version => '1.1.9' or just require rspec-rails if you're using rubygems >= 1.2 (since installing rspec-rails will, by default, install rspec) # OK config.gem 'rspec-rails', :lib => 'spec/rails', :version => '1.1.9' Keep your eye on the ticket (http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/577) to see when this is resolved. Cheers, David From charles.nutter at sun.com Fri Oct 24 01:03:55 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 24 Oct 2008 00:03:55 -0500 Subject: [rspec-devel] [ANN] rspec 1.1.9 Released In-Reply-To: <57c63afe0810202214w3c163bercf78c55f81e78aa2@mail.gmail.com> References: <57c63afe0810202214w3c163bercf78c55f81e78aa2@mail.gmail.com> Message-ID: <4901573B.5090106@sun.com> It seems the spec task somehow depends on spicycode-rcov, which is not available on RubyForge. Was that an unintentional glitch? - Charlie David Chelimsky wrote: > rspec version 1.1.9 has been released! > > * > > Behaviour Driven Development for Ruby. > > Changes: > > ### Version 1.1.9 / 2008-10-20 > > WARNING: This release removes implicit inclusion of modules in example groups. > This means that if you have 'describe MyModule do', MyModule will not be > included in the group. > > * 2 major enhancements > > * Add extend to configuration (thanks to advice from Chad Fowler) > * Modules are no longer implicitly included in example groups > > * 4 minor enhancements > > * mingw indicates windows too (thanks to Luis Lavena for the tip) > * improved output for partial mock expecation failures > * it_should_behave_like now accepts n names of shared groups > * eliminated redundant inclusion/extension of ExampleGroupMethods > > * 6 bug fixes > > * spec command with no arguments prints help > * fixed typo in help. Fixes #73. > * fixed bug where should_receive..and_yield after similar stub added > the args_to_yield to the stub's original args_to_yield (Pat Maddox) > * fixed bug where rspec-autotest (autospec) was loading non-spec > files in spec directory. Fixes #559. > * fixed bug where should_not_receive was reporting twice > * fixed bug where rspec tries to run examples just because it is > required (even if there are no examples loaded). Fixes #575. > > * > From ben at benmabey.com Fri Oct 24 02:57:54 2008 From: ben at benmabey.com (Ben Mabey) Date: Fri, 24 Oct 2008 00:57:54 -0600 Subject: [rspec-devel] [ANN] rspec 1.1.9 Released In-Reply-To: <4901573B.5090106@sun.com> References: <57c63afe0810202214w3c163bercf78c55f81e78aa2@mail.gmail.com> <4901573B.5090106@sun.com> Message-ID: <490171F2.3080003@benmabey.com> Charles Oliver Nutter wrote: > It seems the spec task somehow depends on spicycode-rcov, which is not > available on RubyForge. Was that an unintentional glitch? > > - Charlie According to David it was unintentional and the dependency won't be there for the next release. This was brought up on rspec-users mailing list earlier today and this was David's reply: http://rubyforge.org/pipermail/rspec-users/2008-October/009642.html HTH, Ben > > David Chelimsky wrote: >> rspec version 1.1.9 has been released! >> >> * >> >> Behaviour Driven Development for Ruby. >> >> Changes: >> >> ### Version 1.1.9 / 2008-10-20 >> >> WARNING: This release removes implicit inclusion of modules in >> example groups. >> This means that if you have 'describe MyModule do', MyModule will not be >> included in the group. >> >> * 2 major enhancements >> >> * Add extend to configuration (thanks to advice from Chad Fowler) >> * Modules are no longer implicitly included in example groups >> >> * 4 minor enhancements >> >> * mingw indicates windows too (thanks to Luis Lavena for the tip) >> * improved output for partial mock expecation failures >> * it_should_behave_like now accepts n names of shared groups >> * eliminated redundant inclusion/extension of ExampleGroupMethods >> >> * 6 bug fixes >> >> * spec command with no arguments prints help >> * fixed typo in help. Fixes #73. >> * fixed bug where should_receive..and_yield after similar stub added >> the args_to_yield to the stub's original args_to_yield (Pat Maddox) >> * fixed bug where rspec-autotest (autospec) was loading non-spec >> files in spec directory. Fixes #559. >> * fixed bug where should_not_receive was reporting twice >> * fixed bug where rspec tries to run examples just because it is >> required (even if there are no examples loaded). Fixes #575. >> >> * >> > > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dchelimsky at gmail.com Fri Oct 24 03:00:57 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Fri, 24 Oct 2008 02:00:57 -0500 Subject: [rspec-devel] [ANN] rspec 1.1.9 Released In-Reply-To: <490171F2.3080003@benmabey.com> References: <57c63afe0810202214w3c163bercf78c55f81e78aa2@mail.gmail.com> <4901573B.5090106@sun.com> <490171F2.3080003@benmabey.com> Message-ID: <57c63afe0810240000i61186667x77d3f33492e2683f@mail.gmail.com> On Fri, Oct 24, 2008 at 1:57 AM, Ben Mabey wrote: > Charles Oliver Nutter wrote: >> >> It seems the spec task somehow depends on spicycode-rcov, which is not >> available on RubyForge. Was that an unintentional glitch? >> >> - Charlie > > > According to David it was unintentional and the dependency won't be there > for the next release. > This was brought up on rspec-users mailing list earlier today and this was > David's reply: > http://rubyforge.org/pipermail/rspec-users/2008-October/009642.html I actually already released 1.1.10, though I have not made a formal announcement. If anyone cares to upgrade, please do so and let me know if you run into any problems. Of course, you shouldn't :) Cheers, David > > HTH, > Ben > >> >> David Chelimsky wrote: >>> >>> rspec version 1.1.9 has been released! >>> >>> * >>> >>> Behaviour Driven Development for Ruby. >>> >>> Changes: >>> >>> ### Version 1.1.9 / 2008-10-20 >>> >>> WARNING: This release removes implicit inclusion of modules in example >>> groups. >>> This means that if you have 'describe MyModule do', MyModule will not be >>> included in the group. >>> >>> * 2 major enhancements >>> >>> * Add extend to configuration (thanks to advice from Chad Fowler) >>> * Modules are no longer implicitly included in example groups >>> >>> * 4 minor enhancements >>> >>> * mingw indicates windows too (thanks to Luis Lavena for the tip) >>> * improved output for partial mock expecation failures >>> * it_should_behave_like now accepts n names of shared groups >>> * eliminated redundant inclusion/extension of ExampleGroupMethods >>> >>> * 6 bug fixes >>> >>> * spec command with no arguments prints help >>> * fixed typo in help. Fixes #73. >>> * fixed bug where should_receive..and_yield after similar stub added >>> the args_to_yield to the stub's original args_to_yield (Pat Maddox) >>> * fixed bug where rspec-autotest (autospec) was loading non-spec >>> files in spec directory. Fixes #559. >>> * fixed bug where should_not_receive was reporting twice >>> * fixed bug where rspec tries to run examples just because it is >>> required (even if there are no examples loaded). Fixes #575. >>> >>> * >>> >> >> _______________________________________________ >> 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 Oct 29 20:04:26 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Wed, 29 Oct 2008 19:04:26 -0500 Subject: [rspec-devel] cucumber steps and step matchers Message-ID: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> In cucumber, I've started to refer to the steps in the scenarios as "steps", and the code that defines them "step matchers": Scenario: blah Given this is a "step" Given /this is step matcher/ do I'd like to propose standardizing on this nomenclature, as I think it makes a much more clear distinction between the steps and the code that runs them. I'd also propose that the following directory structure convention: features/ features/step_matchers # step matchers ONLY features/support # env.rb, etc Obviously everyone is free to organize things as they like, but I'd like to see the cucumber generators lay things out like this (which I'll be happy to implement if we agree on the convention). Thoughts? David From aslak.hellesoy at gmail.com Thu Oct 30 05:45:21 2008 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 30 Oct 2008 10:45:21 +0100 Subject: [rspec-devel] cucumber steps and step matchers In-Reply-To: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> References: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> Message-ID: <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> On Thu, Oct 30, 2008 at 1:04 AM, David Chelimsky wrote: > In cucumber, I've started to refer to the steps in the scenarios as > "steps", and the code that defines them "step matchers": > I have also called them "step definitions" There are two parts to it - the matcher (regexp) and the code (proc) I think the code/implementation part is more important than the matching part. So maybe we should call them "step_implementations"? Vote: "step matchers" - step_matchers/ "step definitions" - step_definitions/ "step implementations" - step_implementations/ > Scenario: blah > Given this is a "step" > > Given /this is step matcher/ do > > I'd like to propose standardizing on this nomenclature, as I think it > makes a much more clear distinction between the steps and the code > that runs them. > > I'd also propose that the following directory structure convention: > > features/ > features/step_matchers # step matchers ONLY > features/support # env.rb, etc > I like the idea of a support directory! > Obviously everyone is free to organize things as they like, but I'd > like to see the cucumber generators lay things out like this (which > I'll be happy to implement if we agree on the convention). > > Thoughts? > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From adam at thewilliams.ws Thu Oct 30 06:05:56 2008 From: adam at thewilliams.ws (Adam Williams) Date: Thu, 30 Oct 2008 06:05:56 -0400 Subject: [rspec-devel] cucumber steps and step matchers In-Reply-To: <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> References: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> Message-ID: <1F69894F-D0F1-433D-B8A8-89E9F851B4F4@thewilliams.ws> On Oct 30, 2008, at 5:45 AM, aslak hellesoy wrote: > "step matchers" - step_matchers/ 2 > "step definitions" - step_definitions/ 1 > "step implementations" - step_implementations/ 3 From chad.humphries at gmail.com Thu Oct 30 07:18:30 2008 From: chad.humphries at gmail.com (Chad Humphries) Date: Thu, 30 Oct 2008 07:18:30 -0400 Subject: [rspec-devel] cucumber steps and step matchers In-Reply-To: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> References: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> Message-ID: <16f722280810300418v7c1b2458gb1463a5a7d17a0d5@mail.gmail.com> That's how we have it set up, we just had support as supporting. I think this will be helpful to someone getting into cucumber to have this in place. -- Chad On Wed, Oct 29, 2008 at 8:04 PM, David Chelimsky wrote: > In cucumber, I've started to refer to the steps in the scenarios as > "steps", and the code that defines them "step matchers": > > Scenario: blah > Given this is a "step" > > Given /this is step matcher/ do > > I'd like to propose standardizing on this nomenclature, as I think it > makes a much more clear distinction between the steps and the code > that runs them. > > I'd also propose that the following directory structure convention: > > features/ > features/step_matchers # step matchers ONLY > features/support # env.rb, etc > > Obviously everyone is free to organize things as they like, but I'd > like to see the cucumber generators lay things out like this (which > I'll be happy to implement if we agree on the convention). > > Thoughts? > David > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From chad.humphries at gmail.com Thu Oct 30 07:22:00 2008 From: chad.humphries at gmail.com (Chad Humphries) Date: Thu, 30 Oct 2008 07:22:00 -0400 Subject: [rspec-devel] RCov --spec-only option Message-ID: <16f722280810300422ueb83d97h67155a7a69c1b7d5@mail.gmail.com> Hey guys, I fixed the rcov option for --spec-only last night (version 0.8.1.5.0 should have the update in it from github). It should be working against master and the latest gem releases of RSpec. I just wanted to ask, did anyone here use the option before? I'm trying to gauge what the user base/desire is for it. Cheers, Chad From chad.humphries at gmail.com Thu Oct 30 07:27:11 2008 From: chad.humphries at gmail.com (Chad Humphries) Date: Thu, 30 Oct 2008 07:27:11 -0400 Subject: [rspec-devel] Pulling the story runner out of rspec/rspec-rails Message-ID: <16f722280810300427l635a5116w1068a85270e3295f@mail.gmail.com> Hey again, I've been working on my fork of RSpec recently and I have removed story runner a few different ways. I can pull it out into it's own gem fairly quickly, although the gem will require a little more of my time to make it prim and proper for public consumption. My question is this, do you still want the story runner pulled out into a separate gem? I'm not interested into maintaining it long-term, but I do have some time to take care of the extraction and hand off to whomever would like to. Cheers, Chad From dchelimsky at gmail.com Thu Oct 30 09:56:46 2008 From: dchelimsky at gmail.com (David Chelimsky) Date: Thu, 30 Oct 2008 08:56:46 -0500 Subject: [rspec-devel] Pulling the story runner out of rspec/rspec-rails In-Reply-To: <16f722280810300427l635a5116w1068a85270e3295f@mail.gmail.com> References: <16f722280810300427l635a5116w1068a85270e3295f@mail.gmail.com> Message-ID: <57c63afe0810300656l5c8f185bjb1c6dda9b27b0e61@mail.gmail.com> On Thu, Oct 30, 2008 at 6:27 AM, Chad Humphries wrote: > Hey again, > > I've been working on my fork of RSpec recently and I have removed > story runner a few different ways. I can pull it out into it's own > gem fairly quickly, although the gem will require a little more of my > time to make it prim and proper for public consumption. My question > is this, do you still want the story runner pulled out into a separate > gem? I'm not interested into maintaining it long-term, but I do have > some time to take care of the extraction and hand off to whomever > would like to. This is definitely in the plan. I wasn't planning to tackle it until later this year, perhaps early '09, but if you can get it working and clean and simple (so there is a separate rspec-stories gem), then I'd be glad to release it sooner. Thanks for the effort! Cheers, David > > Cheers, > > Chad > _______________________________________________ > rspec-devel mailing list > rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From pergesu at gmail.com Thu Oct 30 16:03:05 2008 From: pergesu at gmail.com (Pat Maddox) Date: Thu, 30 Oct 2008 13:03:05 -0700 Subject: [rspec-devel] cucumber steps and step matchers In-Reply-To: <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> (aslak hellesoy's message of "Thu\, 30 Oct 2008 10\:45\:21 +0100") References: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> Message-ID: "aslak hellesoy" writes: > Vote: > > "step matchers" - step_matchers/ > "step definitions" - step_definitions/ > "step implementations" - step_implementations/ I've been using "step definitions." I think that's the most sense...the step definition is the matcher + implementation. Pat From josephwilk at joesniff.co.uk Fri Oct 31 10:38:52 2008 From: josephwilk at joesniff.co.uk (Joseph Wilk-2) Date: Fri, 31 Oct 2008 07:38:52 -0700 (PDT) Subject: [rspec-devel] cucumber steps and step matchers In-Reply-To: <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> References: <57c63afe0810291704u24e8440ew71714b6da908f49a@mail.gmail.com> <8d961d900810300245w1b50ad16v78f1c8007dae11df@mail.gmail.com> Message-ID: <20267262.post@talk.nabble.com> >"step matchers" - step_matchers/ - 2 >"step definitions" - step_definitions/ - 1 >"step implementations" - step_implementations/ - 3 -- Joseph Wilk -- View this message in context: http://www.nabble.com/cucumber-steps-and-step-matchers-tp20240928p20267262.html Sent from the rspec-devel mailing list archive at Nabble.com.