From aslak.hellesoy at gmail.com Mon May 1 20:15:34 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 1 May 2006 19:15:34 -0500 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> Message-ID: <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> I have applied Rich's sweet patch. http://rspec.rubyforge.org/documentation/underscores.html I tweaked a little so it works with mocks too. For now you have to run with --sweet - it's disabled by default. If, at a later stage we can establish that most of the rspec users prefer the underscore (I am one of them) then I suggest we make underscores enabled by default and update the documentation to use underscores everywhere. WDYT? Aslak From aslak.hellesoy at gmail.com Tue May 2 00:26:06 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 1 May 2006 23:26:06 -0500 Subject: [Rspec-devel] PROPOSAL: --format and --dry-run Message-ID: <8d961d900605012126m2b966b7ak516d95cc99e7c1b8@mail.gmail.com> Hi, I'm planning to add tool number eight to http://rspec.rubyforge.org/tools/index.html: HTML reports a la http://forge.objectweb.org/nightlybuilds/c-jdbc/tests/today/overview-summary.html (except a better browsing experience). HTML reports are particularly useful for larger projects, especially when specs are run on a continuous integration server - it makes it easier to spot the errors when they occur. I've done some refactorings in svn to make this a little easier. The old SimpleTextReporter is now two classes: Reporter and TextOutputter (Reporter has-a Reporter is the plan). I'd like to be able to specify the reporter on the command line via a --format option. It seems natural to use this option to specify --format=text (default), --format=rdoc and --format-html. So I'm planning a HtmlOutputter. Some additional refactorings would make this a little cleaner. First of all, the current --verbose option results in output that is very similar to the output produced by --doc. I propose to remove both of these options. --verbose becomes --format=rdoc --doc becomes --format=rdoc --dry-run The assumption here is that the rdoc format: # BDD framework # * should be adopted quickly # * should be intuitive is readable enough as it is in the console. The --dry-run option would only generate output (with whatever --format is specified), without actually running the specs. --dry-run is a common option for many other command line tools. I think these proposed command line changes would make the interface cleaner, as well as clean up some duplication inside rspec. What do you think? Aslak From dchelimsky at gmail.com Tue May 2 08:09:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 2 May 2006 07:09:25 -0500 Subject: [Rspec-devel] PROPOSAL: --format and --dry-run In-Reply-To: <8d961d900605012126m2b966b7ak516d95cc99e7c1b8@mail.gmail.com> References: <8d961d900605012126m2b966b7ak516d95cc99e7c1b8@mail.gmail.com> Message-ID: <57c63afe0605020509x67557df7v842ddfa48a8e6906@mail.gmail.com> I ALWAYS On 5/1/06, aslak hellesoy wrote: > Hi, > > I'm planning to add tool number eight to > http://rspec.rubyforge.org/tools/index.html: > HTML reports a la > http://forge.objectweb.org/nightlybuilds/c-jdbc/tests/today/overview-summary.html > (except a better browsing experience). HTML reports are particularly > useful for larger projects, especially when specs are run on a > continuous integration server - it makes it easier to spot the errors > when they occur. > > I've done some refactorings in svn to make this a little easier. The > old SimpleTextReporter is now two classes: Reporter and TextOutputter > (Reporter has-a Reporter is the plan). > > I'd like to be able to specify the reporter on the command line via a > --format option. > It seems natural to use this option to specify --format=text > (default), --format=rdoc and --format-html. So I'm planning a > HtmlOutputter. > > Some additional refactorings would make this a little cleaner. First > of all, the current --verbose option results in output that is very > similar to the output produced by --doc. I propose to remove both of > these options. > > --verbose becomes --format=rdoc > --doc becomes --format=rdoc --dry-run > > The assumption here is that the rdoc format: > # BDD framework > # * should be adopted quickly > # * should be intuitive > > is readable enough as it is in the console. > > The --dry-run option would only generate output (with whatever > --format is specified), without actually running the specs. --dry-run > is a common option for many other command line tools. > > I think these proposed command line changes would make the interface > cleaner, as well as clean up some duplication inside rspec. > > What do you think? > > Aslak > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue May 2 08:10:45 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 2 May 2006 07:10:45 -0500 Subject: [Rspec-devel] PROPOSAL: --format and --dry-run In-Reply-To: <57c63afe0605020509x67557df7v842ddfa48a8e6906@mail.gmail.com> References: <8d961d900605012126m2b966b7ak516d95cc99e7c1b8@mail.gmail.com> <57c63afe0605020509x67557df7v842ddfa48a8e6906@mail.gmail.com> Message-ID: <57c63afe0605020510s4aaa94c3sf5198c84ea8c4bf@mail.gmail.com> DOH! Hit send somehow. More on that later.... On 5/2/06, David Chelimsky wrote: > I ALWAYS > > On 5/1/06, aslak hellesoy wrote: > > Hi, > > > > I'm planning to add tool number eight to > > http://rspec.rubyforge.org/tools/index.html: > > HTML reports a la > > http://forge.objectweb.org/nightlybuilds/c-jdbc/tests/today/overview-summary.html > > (except a better browsing experience). HTML reports are particularly > > useful for larger projects, especially when specs are run on a > > continuous integration server - it makes it easier to spot the errors > > when they occur. > > > > I've done some refactorings in svn to make this a little easier. The > > old SimpleTextReporter is now two classes: Reporter and TextOutputter > > (Reporter has-a Reporter is the plan). > > > > I'd like to be able to specify the reporter on the command line via a > > --format option. > > It seems natural to use this option to specify --format=text > > (default), --format=rdoc and --format-html. So I'm planning a > > HtmlOutputter. > > > > Some additional refactorings would make this a little cleaner. First > > of all, the current --verbose option results in output that is very > > similar to the output produced by --doc. I propose to remove both of > > these options. > > > > --verbose becomes --format=rdoc > > --doc becomes --format=rdoc --dry-run > > > > The assumption here is that the rdoc format: > > # BDD framework > > # * should be adopted quickly > > # * should be intuitive > > > > is readable enough as it is in the console. > > > > The --dry-run option would only generate output (with whatever > > --format is specified), without actually running the specs. --dry-run > > is a common option for many other command line tools. > > > > I think these proposed command line changes would make the interface > > cleaner, as well as clean up some duplication inside rspec. > > > > What do you think? > > > > Aslak > > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dchelimsky at gmail.com Tue May 2 08:46:12 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 2 May 2006 07:46:12 -0500 Subject: [Rspec-devel] PROPOSAL: --format and --dry-run In-Reply-To: <57c63afe0605020510s4aaa94c3sf5198c84ea8c4bf@mail.gmail.com> References: <8d961d900605012126m2b966b7ak516d95cc99e7c1b8@mail.gmail.com> <57c63afe0605020509x67557df7v842ddfa48a8e6906@mail.gmail.com> <57c63afe0605020510s4aaa94c3sf5198c84ea8c4bf@mail.gmail.com> Message-ID: <57c63afe0605020546h99ea169p63ee4280c23eac9a@mail.gmail.com> I'm on board for eliminating --verbose and --doc. I like the idea of a switch to supply the formatter, but I'd like it to be optionally less verbose. I always use the -v switch, and I wouldn't want to have to type all of that to get the same effect. Also, maybe I'm just used to the format I'm used to, but I'd like the current verbose format to be available in addition to the rdoc format. That format is also the same as agiledox, so it will be familiar to anyone who's used that tool. So I'd propose something like this: --format OR -f sets the formatter (default is the current default -- dots and Fs) legal values for this option would be: doc rdoc html and you can use the first letter of each as a shortcut d r h So, for clarity in shell scripts, for example, you might type this: spec . --format html while on the command line you might abbreviate: spec . -f h "doc" or "d" gets you this: BDD framework - should be adopted quickly - should be intuitive "rdoc" or "r" gets you this: # BDD framework # * should be adopted quickly # * should be intuitive "html" or "h" gets you html The only think I'm not sure about is the --dry-run option. I think that I'd like the option to add that for the doc format, but that for the rdoc format, which would generally be used specifically to generate rdocs, dry-run should be the default. Would that be too confusing? Also, I'd propose that we supply messages for --verbose and --doc that explain that these options are no longer valid and what to use. Only for the next release or so. Thoughts? On 5/2/06, David Chelimsky wrote: > DOH! > > Hit send somehow. More on that later.... > > On 5/2/06, David Chelimsky wrote: > > I ALWAYS > > > > On 5/1/06, aslak hellesoy wrote: > > > Hi, > > > > > > I'm planning to add tool number eight to > > > http://rspec.rubyforge.org/tools/index.html: > > > HTML reports a la > > > http://forge.objectweb.org/nightlybuilds/c-jdbc/tests/today/overview-summary.html > > > (except a better browsing experience). HTML reports are particularly > > > useful for larger projects, especially when specs are run on a > > > continuous integration server - it makes it easier to spot the errors > > > when they occur. > > > > > > I've done some refactorings in svn to make this a little easier. The > > > old SimpleTextReporter is now two classes: Reporter and TextOutputter > > > (Reporter has-a Reporter is the plan). > > > > > > I'd like to be able to specify the reporter on the command line via a > > > --format option. > > > It seems natural to use this option to specify --format=text > > > (default), --format=rdoc and --format-html. So I'm planning a > > > HtmlOutputter. > > > > > > Some additional refactorings would make this a little cleaner. First > > > of all, the current --verbose option results in output that is very > > > similar to the output produced by --doc. I propose to remove both of > > > these options. > > > > > > --verbose becomes --format=rdoc > > > --doc becomes --format=rdoc --dry-run > > > > > > The assumption here is that the rdoc format: > > > # BDD framework > > > # * should be adopted quickly > > > # * should be intuitive > > > > > > is readable enough as it is in the console. > > > > > > The --dry-run option would only generate output (with whatever > > > --format is specified), without actually running the specs. --dry-run > > > is a common option for many other command line tools. > > > > > > I think these proposed command line changes would make the interface > > > cleaner, as well as clean up some duplication inside rspec. > > > > > > What do you think? > > > > > > Aslak > > > > > > _______________________________________________ > > > Rspec-devel mailing list > > > Rspec-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > > > > From dchelimsky at gmail.com Tue May 2 20:35:12 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 2 May 2006 19:35:12 -0500 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> Message-ID: <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> It turns out with --sweet both this.syntax and this_syntax are supported. My thinking is we remove the switch (which only serves to complain if you use the sweet_syntax without the sweet_switch) and just have it running all the time (supporting both). Agree? On 5/1/06, aslak hellesoy wrote: > I have applied Rich's sweet patch. > http://rspec.rubyforge.org/documentation/underscores.html > I tweaked a little so it works with mocks too. > > For now you have to run with --sweet - it's disabled by default. > > If, at a later stage we can establish that most of the rspec users > prefer the underscore (I am one of them) then I suggest we make > underscores enabled by default and update the documentation to use > underscores everywhere. > > WDYT? > Aslak > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue May 2 20:37:46 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 2 May 2006 19:37:46 -0500 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> Message-ID: <8d961d900605021737p35b5686td9d6408cd46c15b4@mail.gmail.com> On 5/2/06, David Chelimsky wrote: > It turns out with --sweet both this.syntax and this_syntax are > supported. My thinking is we remove the switch (which only serves to > complain if you use the sweet_syntax without the sweet_switch) and > just have it running all the time (supporting both). > > Agree? > +1 > On 5/1/06, aslak hellesoy wrote: > > I have applied Rich's sweet patch. > > http://rspec.rubyforge.org/documentation/underscores.html > > I tweaked a little so it works with mocks too. > > > > For now you have to run with --sweet - it's disabled by default. > > > > If, at a later stage we can establish that most of the rspec users > > prefer the underscore (I am one of them) then I suggest we make > > underscores enabled by default and update the documentation to use > > underscores everywhere. > > > > WDYT? > > Aslak > > > > _______________________________________________ > > 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 dastels at daveastels.com Tue May 2 20:43:17 2006 From: dastels at daveastels.com (David Astels) Date: Tue, 2 May 2006 21:43:17 -0300 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> Message-ID: On 2-May-06, at 9:35 PM, David Chelimsky wrote: > It turns out with --sweet both this.syntax and this_syntax are > supported. My thinking is we remove the switch (which only serves to > complain if you use the sweet_syntax without the sweet_switch) and > just have it running all the time (supporting both). > > Agree? +1 Dave From dchelimsky at gmail.com Tue May 2 20:48:21 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 2 May 2006 19:48:21 -0500 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> Message-ID: <57c63afe0605021748w563827e5xc8f0f062f5a65306@mail.gmail.com> 2 is good enough for me. I'll address that this evening. On 5/2/06, David Astels wrote: > > On 2-May-06, at 9:35 PM, David Chelimsky wrote: > > > It turns out with --sweet both this.syntax and this_syntax are > > supported. My thinking is we remove the switch (which only serves to > > complain if you use the sweet_syntax without the sweet_switch) and > > just have it running all the time (supporting both). > > > > Agree? > > +1 > > Dave > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From dchelimsky at gmail.com Tue May 2 22:10:30 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 2 May 2006 21:10:30 -0500 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: <57c63afe0605021748w563827e5xc8f0f062f5a65306@mail.gmail.com> References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> <57c63afe0605021748w563827e5xc8f0f062f5a65306@mail.gmail.com> Message-ID: <57c63afe0605021910l3adb1e42v4ce4ae7d4a40eab3@mail.gmail.com> Done. Specs are now always pre-sweetened. Perhaps you'd like lemon with that spec? On 5/2/06, David Chelimsky wrote: > 2 is good enough for me. I'll address that this evening. > > On 5/2/06, David Astels wrote: > > > > On 2-May-06, at 9:35 PM, David Chelimsky wrote: > > > > > It turns out with --sweet both this.syntax and this_syntax are > > > supported. My thinking is we remove the switch (which only serves to > > > complain if you use the sweet_syntax without the sweet_switch) and > > > just have it running all the time (supporting both). > > > > > > Agree? > > > > +1 > > > > Dave > > > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From byronsalty at gmail.com Wed May 3 11:17:04 2006 From: byronsalty at gmail.com (Byron Saltysiak) Date: Wed, 3 May 2006 11:17:04 -0400 Subject: [Rspec-devel] possible addition to expectations... In-Reply-To: <57c63afe0605021910l3adb1e42v4ce4ae7d4a40eab3@mail.gmail.com> References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <8d961d900605011715rb1f878ct91a04a8064a96c36@mail.gmail.com> <57c63afe0605021735g15f90134s4a93a1ec2c75d2e5@mail.gmail.com> <57c63afe0605021748w563827e5xc8f0f062f5a65306@mail.gmail.com> <57c63afe0605021910l3adb1e42v4ce4ae7d4a40eab3@mail.gmail.com> Message-ID: <787687ba0605030817t752460fw3e65156f4ead07fb@mail.gmail.com> very nice :) On 5/2/06, David Chelimsky wrote: > > Done. Specs are now always pre-sweetened. Perhaps you'd like lemon > with that spec? > > On 5/2/06, David Chelimsky wrote: > > 2 is good enough for me. I'll address that this evening. > > > > On 5/2/06, David Astels wrote: > > > > > > On 2-May-06, at 9:35 PM, David Chelimsky wrote: > > > > > > > It turns out with --sweet both this.syntax and this_syntax are > > > > supported. My thinking is we remove the switch (which only serves to > > > > complain if you use the sweet_syntax without the sweet_switch) and > > > > just have it running all the time (supporting both). > > > > > > > > Agree? > > > > > > +1 > > > > > > Dave > > > > > > _______________________________________________ > > > 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 > -- Byron http://byron.saltysiak.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060503/f52f2e4c/attachment.htm From scottlholmes at gmail.com Wed May 3 13:15:38 2006 From: scottlholmes at gmail.com (Scott L Holmes) Date: Wed, 3 May 2006 13:15:38 -0400 Subject: [Rspec-devel] Advice Needed Message-ID: <1d2765540605031015p47b86203s8f3520fc974e8ae8@mail.gmail.com> I've been looking at rspec for some time now. I like very much your methodolgy and the code is top-knotch. I would like to incorporate rspec in an environment that I'm building for JRuby. So far so good. At minimum, the context and their specifications would be stored in sort of a knowledgebase - so instead of: $ spec stack_spec.rb I have more like: ProjectSpecification.new("stack_spec").execute ProjectSpecificiation merely retrieves the contexts and specs from the kb and then (somehow?) submits them to spec. Right now, I'm just constructing a simple context and using eval to "run" it. Now what I don't want to do is code myself in a corner - eventually, I'd like to be able to make use of the runners and reports you have. Can you make suggestions for future-proofing my environment which merely seeks to "store" rspecs? Sorry, I'm only just getting started on rspec's API - is there a point in the api you can steer me to (it's quite dense). Appreciate your time. You're system is phenomenal - paradigm shifting really - very well done. Scott L Holmes http://www.slholmes.org/ <= more clues about what I'm doing -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060503/8fdaa2f6/attachment.htm From scottlholmes at gmail.com Fri May 5 07:48:02 2006 From: scottlholmes at gmail.com (Scott L Holmes) Date: Fri, 5 May 2006 07:48:02 -0400 Subject: [Rspec-devel] Advice Needed In-Reply-To: <1d2765540605031015p47b86203s8f3520fc974e8ae8@mail.gmail.com> References: <1d2765540605031015p47b86203s8f3520fc974e8ae8@mail.gmail.com> Message-ID: <1d2765540605050448r169bd852y240253ed946dd0ce@mail.gmail.com> Nothing worse in a forum than a question with no answer, so I'll update this with my progress: require 'spec' context_runner = Spec::Runner::ContextRunner.new(["-v"],[nil]) Spec::Runner::Context.context_runner = context_runner Hopefully, there's no adverse side affects for initializing the runner with an empty filename array. So, far so good. By associating the context_runner with the class Spec::Runner::Context, we can created new Context objects and they'll be automatically be added to the runner. Given this (and a database reader thing), we add contexts to the runner thusly: context = Spec::Runner::Context.new(dbthing.get_context_name) do eval("setup {#{dbthing.get_context_setup_block_text}}") dbthing.get_specifies.each {|specification| eval("specify('#{specification.get_specify_name}') {#{ specification.get_spec_block_text}}") } eval("teardown {#{dbthing.get_context_teardown_block_text}}") end I need to come up with a straight forward approach to translating Ruby Code stored in a String into a block so that I could just do this setup dbthing.get_context_setup_block_text.to_block I've not been able to find anything on the web yet that gets me there and I'm too new to Ruby to make the connections on my own. Anyway, we can run the whole thing by running the runner: context_runner.run Scott On 5/3/06, Scott L Holmes wrote: > > I've been looking at rspec for some time now. I like very much your > methodolgy and the code is top-knotch. > > I would like to incorporate rspec in an environment that I'm building for > JRuby. So far so good. At minimum, the context and their specifications > would be stored in sort of a knowledgebase - so instead of: > > $ spec stack_spec.rb > > I have more like: > > ProjectSpecification.new("stack_spec").execute > > ProjectSpecificiation merely retrieves the contexts and specs from the kb > and then (somehow?) submits them to spec. Right now, I'm just constructing a > simple context and using eval to "run" it. > > Now what I don't want to do is code myself in a corner - eventually, I'd > like to be able to make use of the runners and reports you have. Can you > make suggestions for future-proofing my environment which merely seeks to > "store" rspecs? Sorry, I'm only just getting started on rspec's API - is > there a point in the api you can steer me to (it's quite dense). > > Appreciate your time. You're system is phenomenal - paradigm shifting > really - very well done. > > Scott L Holmes > http://www.slholmes.org/ <= more clues about what I'm doing > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060505/17cda3b5/attachment.htm From Keith.Hodges at warwick.ac.uk Sat May 6 06:44:26 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Sat, 06 May 2006 11:44:26 +0100 Subject: [Rspec-devel] Adaptation of rpsec Message-ID: <445C7E0A.5@warwick.ac.uk> Hello, I have been working on an adaptation of rpsec in javascript. My code may be a bit ropey but I think idea has some merit: I have included an example spec below. I use the word "expect" or "dontWant" to start sentences. I think that this may be more portable than the rspec approach since I didn't want to add methods to all objects in javascript. I love the ability to test more than one thing at once expect( a,b,c ).toBe( 3 ).or().toBe(5) Specifications may be nested and supply setUp/tearDown for their children. This gives the spec a tree structure and allows fixtures to be branched in order to specify alternative use paths. Any feedback/comments/etc would be welcomed. For code examples etc: http://www.warwick.ac.uk/~tuspam/js_spec/ Keith ======================= Test Something

Specification Testing in Javascript

___________________________________________________________ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com From dchelimsky at gmail.com Sat May 6 08:16:13 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 6 May 2006 08:16:13 -0400 Subject: [Rspec-devel] Adaptation of rpsec In-Reply-To: <445C7E0A.5@warwick.ac.uk> References: <445C7E0A.5@warwick.ac.uk> Message-ID: <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> Hi Keith, Thanks for doing this. It's a great start. Here are some initial reactions to the things that you chose to do differently from rspec. Keep in mind that these are MY opinions and I don't expect you to change anything on my account. But please also keep in mind that I got interested w/ BDD and rspec because they begin to solve very specific problems that I've experienced over years of using xUnit frameworks. 1) "expect" and "dontWant" don't read as opposites to me. rspec uses should_be and should_not_be, which are more obvious opposites. So expressing it like this: expect(3).toBe(3); expect(5).toNotBe(5); or expect(5).notToBe(3); would be more in keeping w/ rspec's approach, and more readable in my view. 2) Nested specifications. One of the pitfalls of xUnit frameworks is the tendency of developers to use inheritance to eliminate duplication in setting up test fixtures. Things become very difficult to grok - especially when there's a failure you're trying to understand. We had some discussion of supporting hierarchies in rspec and more or less agreed not to for the time being for that very reason. 3) Multiple expectations per expression (expect(a).toBe(3).and(b).toBe(5))). I think this ends up more confusing than just expressing the expectations separately. A key goal should be consistency in expression and to make things more readable. This would violate that consistency in my view. Also, what is the use of or()? Why would you want to allow for any variation in the result? That's just asking for bugs and headaches. 4) The specify()/specified() structure feels a little funny. Can you move whatever is happening in specified() to specify()? So if there is a specification being described, wrap it up. Then begin a new one. It looks like you need to indicate the end of a specification for nesting, but I already expressed my concern about nesting. I guess you would have to do the same thing when closing the context, so maybe it's best the way it is already. That's all for the moment. Feel free to respond if you so desire. And thanks again for doing this and sharing it with us. Cheers, David On 5/6/06, Keith Hodges wrote: > Hello, > > I have been working on an adaptation of rpsec in javascript. My code may > be a bit ropey but I think idea has some merit: > > I have included an example spec below. > > I use the word "expect" or "dontWant" to start sentences. I think that > this may be more portable than the rspec approach since I didn't want to > add methods to all objects in javascript. > > I love the ability to test more than one thing at once > expect( a,b,c ).toBe( 3 ).or().toBe(5) > > Specifications may be nested and supply setUp/tearDown for their > children. This gives the spec a tree structure and allows fixtures to be > branched in order to specify alternative use paths. > > Any feedback/comments/etc would be welcomed. > > For code examples etc: > http://www.warwick.ac.uk/~tuspam/js_spec/ > > Keith > > ======================= > > > > Test Something > > > > >

Specification Testing in Javascript

> > > > > > > > > > ___________________________________________________________ > Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From Keith.Hodges at warwick.ac.uk Sat May 6 08:40:20 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Sat, 06 May 2006 13:40:20 +0100 Subject: [Rspec-devel] Adaptation of rpsec In-Reply-To: <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> References: <445C7E0A.5@warwick.ac.uk> <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> Message-ID: <445C9934.2030405@warwick.ac.uk> David Chelimsky wrote: > 1) "expect" and "dontWant" don't read as opposites to me. rspec uses > should_be and should_not_be, which are more obvious opposites. So > expressing it like this: > > expect(3).toBe(3); > expect(5).toNotBe(5); > or > expect(5).notToBe(3); > > Indeed I agonised over the wording for a while, I am open for suggestions/improvements. I did implement the operator 'not' to allow that kind of wording, i.e: expect(5).not().toBe(3) > would be more in keeping w/ rspec's approach, and more readable in my view. > > 2) Nested specifications. One of the pitfalls of xUnit frameworks is > the tendency of developers to use inheritance to eliminate duplication > in setting up test fixtures. Things become very difficult to grok - > especially when there's a failure you're trying to understand. > > Interesting, yes I have done it myself a lot, I have used inheritance a great deal, particularly when testing "the next version" while still needing the ability to test the previous version. > We had some discussion of supporting hierarchies in rspec and more or > less agreed not to for the time being for that very reason. > I am not sure that having an aggregation or tree structure for specifications is as difficult to manage as inheritance. I guess time will tell. > 3) Multiple expectations per expression > (expect(a).toBe(3).and(b).toBe(5))). I think this ends up more > confusing than just expressing the expectations separately. I can see your point particularly with that example in which the expectand is changed by the and(), perhaps that should not be allowed. I wanted to be able to specify things like I want A to be of class "foo" with value 5 in one expectation. > A key goal > should be consistency in expression and to make things more readable. > This would violate that consistency in my view. Also, what is the use > of or()? Why would you want to allow for any variation in the result? > That's just asking for bugs and headaches. > > Oh? I included this on the basis that I would have thought that it would be more common in a specification to have a bit of flexibility specified. Such as "I expect this value to be a range of valid things". > 4) The specify()/specified() structure feels a little funny. Can you > move whatever is happening in specified() to specify()? So if there is > a specification being described, wrap it up. Then begin a new one. It > Ah, this is kind of a legacy feature, I developed JSSpec to be used within tiddlywiki. In this environment the result of each line is evaluated and displayed. This precluded the use of enclosures or a {} or do-end construct to wrap the specification. > That's all for the moment. Feel free to respond if you so desire. And > thanks again for doing this and sharing it with us. > > Cheers, > David thanks for the fairly immediate feedback to chew on Keith ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From Keith.Hodges at warwick.ac.uk Sat May 6 08:41:19 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Sat, 06 May 2006 13:41:19 +0100 Subject: [Rspec-devel] Adaptation of rpsec In-Reply-To: <787687ba0605060446u214ca9d4pa5f2b30e62f22f5e@mail.gmail.com> References: <445C7E0A.5@warwick.ac.uk> <787687ba0605060446u214ca9d4pa5f2b30e62f22f5e@mail.gmail.com> Message-ID: <445C996F.10205@warwick.ac.uk> Byron Saltysiak wrote: > Very impressive. Too bad I don't use JS extensively anymore but if I > do I'll know where to turn later. > Thanks, glad you like it, I don't have a blog, but if I set something up I can let you know. I think that this code would be trivially easy to port to ruby if anyone is interested. Another useful feature is the attributes accessor "at" given - F= { a: 1, b:2} instead of - expect( F.a ).toBe(1) expect( F.b ).toBe(2) 'at' allows - expect( F ).at('a','b').toBe( [1,2] ) expect( F ).at('a').toBe(1).or().at('b').toBe(2) I have also included an xor operator which I figured could be really useful one day. Keith ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From dchelimsky at gmail.com Sat May 6 08:50:45 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 6 May 2006 08:50:45 -0400 Subject: [Rspec-devel] Adaptation of rpsec In-Reply-To: <445C9934.2030405@warwick.ac.uk> References: <445C7E0A.5@warwick.ac.uk> <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> <445C9934.2030405@warwick.ac.uk> Message-ID: <57c63afe0605060550s2a38a764iba2a87bd2efb7039@mail.gmail.com> On 5/6/06, Keith Hodges wrote: > David Chelimsky wrote: > > 3) Multiple expectations per expression > > (expect(a).toBe(3).and(b).toBe(5))). I think this ends up more > > confusing than just expressing the expectations separately. > > A key goal > > should be consistency in expression and to make things more readable. > > This would violate that consistency in my view. Also, what is the use > > of or()? Why would you want to allow for any variation in the result? > > That's just asking for bugs and headaches. > > > Oh? I included this on the basis that I would have thought that it would > be more common in a specification to have a bit of flexibility > specified. Such as "I expect this value to be a range of valid things". Agreed that support for a range of valid things is desirable, but I've usually seen this expressed like expect(a).toBeBetween(3).and(5) or something like that. Using or() allows you to say expect(a).toBe(3).or(7). That just seems odd to me. I can imagine it to be more useful for non-numeric types: expect(newHire).toBe(collegeGraduate).or(justReallySmart). My concern would be misuse (i.e. 3 or 7). But now I sound like the people who created things like static-typing in order to protect developers from their inability to test their code :) From scottlholmes at gmail.com Sun May 7 06:00:06 2006 From: scottlholmes at gmail.com (Scott L Holmes) Date: Sun, 7 May 2006 06:00:06 -0400 Subject: [Rspec-devel] Feedback Message-ID: <1d2765540605070300r7a3dcf2em4b6f91004732bb8d@mail.gmail.com> Page 3 of the tutorial is utterly brilliant. It clears up so many "agile" misconceptions I've had. Very well done. Bring it on, rspec dudes. Scott From dharple at generalconsumption.org Tue May 9 08:31:49 2006 From: dharple at generalconsumption.org (Daniel Harple) Date: Tue, 9 May 2006 14:31:49 +0200 Subject: [Rspec-devel] [PATCH] Adds -I option to spec, error handling on options parse Message-ID: <714AAE35-E43D-428E-98BC-323757B9D67C@generalconsumption.org> This patch adds: * ``-I'' option to the command-line parser. ``-I DIR'' adds DIR to $LOAD_PATH. Multiple ``-I''s may be specified. * Wrapped command-line parsing to catch parsing errors and report them instead of having OptionParser spit out a huge stack trace. -------------- next part -------------- A non-text attachment was scrubbed... Name: rspec-bin-options.patch Type: application/octet-stream Size: 1899 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060509/1d290692/attachment.obj -------------- next part -------------- -- Daniel From dchelimsky at gmail.com Tue May 9 09:35:10 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 9 May 2006 08:35:10 -0500 Subject: [Rspec-devel] [PATCH] Adds -I option to spec, error handling on options parse In-Reply-To: <714AAE35-E43D-428E-98BC-323757B9D67C@generalconsumption.org> References: <714AAE35-E43D-428E-98BC-323757B9D67C@generalconsumption.org> Message-ID: <57c63afe0605090635m1fb036fcg9cbda038baeb1a81@mail.gmail.com> Hi Dan, Thanks for the patch! Definitely like the backtrace cleanup on parse errors, but I wonder what benefit are you seeking in adding directories to the load path? Please explain. We'd prefer patches coming in one feature per patch so that we can consider each feature separately. Also, there are no tests in your patch and that, for us, is an absolute must - we're at 99.3% coverage right now and plan to keep it that way (or better). Lastly, the patch you submitted is against an old revision. In some cases that's not a problem, but in this case some of the code that you've patched is already quite different. So, please resubmit, if you would, 2 separate patches w/ tests against the current revision. Thanks, David On 5/9/06, Daniel Harple wrote: > This patch adds: > > * ``-I'' option to the command-line parser. ``-I DIR'' adds DIR to > $LOAD_PATH. Multiple ``-I''s may be specified. > * Wrapped command-line parsing to catch parsing errors and report > them instead of having OptionParser spit out a huge stack trace. > > > > > -- Daniel > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From dharple at generalconsumption.org Tue May 9 13:14:33 2006 From: dharple at generalconsumption.org (Daniel Harple) Date: Tue, 9 May 2006 19:14:33 +0200 Subject: [Rspec-devel] [PATCH] Adds -I option to spec, error handling on options parse In-Reply-To: <57c63afe0605090635m1fb036fcg9cbda038baeb1a81@mail.gmail.com> References: <714AAE35-E43D-428E-98BC-323757B9D67C@generalconsumption.org> <57c63afe0605090635m1fb036fcg9cbda038baeb1a81@mail.gmail.com> Message-ID: On May 9, 2006, at 3:35 PM, David Chelimsky wrote: > Thanks for the patch! Definitely like the backtrace cleanup on parse > errors, but I wonder what benefit are you seeking in adding > directories to the load path? Please explain. It adds another way to run your specs: 1) $LOAD_PATH manipulation # foo_spec.rb $LOAD_PATH.unshift(File.dirname(__FILE__) + "../lib") require 'my_lib' $ spec spec/foo_spec.rb 2) use Ruby's -I option. Not much gained here. # foo_spec.rb require 'rubygems' require 'spec' require 'my_lib' $ ruby -Ilib spec/foo_spec.rb 3) Use the Rake task # foo_spec.rb require 'my_lib' # Rakefile # ... $ rake spec 4) Proposed -I option for spec # foo_spec.rb require 'my_lib' $ spec -Ilib spec/foo_spec.rb In case (1) and (2) I have to place extra code in my spec to get it up and running. In (3) I must be use rake. With (4), the -I option, I could have a simple alias in my ~/.profile[1]: alias run_spec='spec -Ilib' $ run_spec spec/ # run them all $ run_spec spec/foo_spec.rb # run a specific spec [1]: Ok, this is technically code, too. -------------- next part -------------- A non-text attachment was scrubbed... Name: hide_OptionParser_backtrace.patch Type: application/octet-stream Size: 1477 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060509/b703ccec/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: include_load_path_option.patch Type: application/octet-stream Size: 1220 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060509/b703ccec/attachment-0003.obj -------------- next part -------------- -- Daniel From dastels at daveastels.com Wed May 10 10:52:12 2006 From: dastels at daveastels.com (David Astels) Date: Wed, 10 May 2006 11:52:12 -0300 Subject: [Rspec-devel] cutting over to new svn/trac server Message-ID: Nancy will be finishing up the setup of the new home for repec today. For that she needs a stable repository. I will take a snapshot of the rubyforge repository at noon today (CT), so have anything committed by then. Dave From Keith.Hodges at warwick.ac.uk Fri May 12 09:45:38 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Fri, 12 May 2006 14:45:38 +0100 Subject: [Rspec-devel] Adaptation of rpsec In-Reply-To: <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> References: <445C7E0A.5@warwick.ac.uk> <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> Message-ID: <44649182.4080709@warwick.ac.uk> > We had some discussion of supporting hierarchies in rspec and more or > less agreed not to for the time being for that very reason. > Dear David, I have had a look at your tutorial for the first time and I am beginning to get your point about hierarchies. My code was written months ago in response to David Astels Agile Toolkit interview, which might explain why I seem to have misinterpreted the way that "context" is actually used in rspec. I realised that it was not hierarchy of specifications that I wanted, since this results in wasting time and effort on checking the brackets so to speak. What I really wanted was the ability to construct my "contexts", and my example demonstrates this. I have updated js_spec and the code is somewhat simpler too. http://www.warwick.ac.uk/staff/Keith.Hodges/js_spec/js_spec_0.9b/example.html the code etc is available at: http://www.warwick.ac.uk/staff/Keith.Hodges/js_spec/js_spec_0.9b as ever feedback is welcomed Keith ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From srbaker at pobox.com Fri May 12 13:23:55 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 12 May 2006 10:23:55 -0700 Subject: [Rspec-devel] Subversion Movage Message-ID: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> False alarm on the svn movage. Trac doesn't require a local copy of the repository, so the subversion repo can stay where it is without confusing anyone. -Steven From dastels at daveastels.com Fri May 12 15:23:29 2006 From: dastels at daveastels.com (David Astels) Date: Fri, 12 May 2006 16:23:29 -0300 Subject: [Rspec-devel] Subversion Movage In-Reply-To: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> Message-ID: <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> > > Trac doesn't require a local copy of the repository, so the > subversion repo can stay where it is without confusing anyone. That was only one problem. Rubyforge has proven to be less than reliable.. I've had complaints about it's downtime. Can you get a svn dump of the rspec repo and email it to Nancy please. Dave From srbaker at pobox.com Fri May 12 16:36:10 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 12 May 2006 13:36:10 -0700 Subject: [Rspec-devel] Subversion Movage In-Reply-To: <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> Message-ID: <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> > That was only one problem. Rubyforge has proven to be less than > reliable.. I've had complaints about it's downtime. The only problem has been the permissions issue for the website update. I don't know how this rumour of RubyForge being unreliable got started; it's been a picture of reliability for myself and a half dozen other folks that I know who use it regularly. That it gets a bit slow at Rails Gem time, has been the only complaint. Are there specific dates and times when it's been down that I'm missing? I pull once per hour from three different RubyForge projects, and my script hasn't failed once. -Steven From rich at infoether.com Fri May 12 16:44:50 2006 From: rich at infoether.com (Richard Kilmer) Date: Fri, 12 May 2006 16:44:50 -0400 Subject: [Rspec-devel] Subversion Movage In-Reply-To: <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> Message-ID: RubyForge has a current uptime of 340 days. We have not received any reports of RubyForge non-reliability. It is hammered sometimes when rails releases, but we are working to get it on better bandwidth, and also working on a new rev of rubygems which fixes the index size issues. If you have any specific issue with RF, please email us...we are here to help. Best, Rich On May 12, 2006, at 4:36 PM, Steven R. Baker wrote: >> That was only one problem. Rubyforge has proven to be less than >> reliable.. I've had complaints about it's downtime. > > The only problem has been the permissions issue for the website > update. I don't know how this rumour of RubyForge being unreliable > got started; it's been a picture of reliability for myself and a half > dozen other folks that I know who use it regularly. That it gets a > bit slow at Rails Gem time, has been the only complaint. > > Are there specific dates and times when it's been down that I'm > missing? I pull once per hour from three different RubyForge > projects, and my script hasn't failed once. > > -Steven > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel From dastels at daveastels.com Fri May 12 16:45:54 2006 From: dastels at daveastels.com (David Astels) Date: Fri, 12 May 2006 17:45:54 -0300 Subject: [Rspec-devel] Subversion Movage In-Reply-To: <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> Message-ID: <42916979-C6CB-4598-B520-B4442C75AC89@daveastels.com> On 12-May-06, at 5:36 PM, Steven R. Baker wrote: >> That was only one problem. Rubyforge has proven to be less than >> reliable.. I've had complaints about it's downtime. > > The only problem has been the permissions issue for the website > update. I don't know how this rumour of RubyForge being unreliable > got started; it's been a picture of reliability for myself and a half > dozen other folks that I know who use it regularly. That it gets a > bit slow at Rails Gem time, has been the only complaint. > > Are there specific dates and times when it's been down that I'm > missing? I pull once per hour from three different RubyForge > projects, and my script hasn't failed once. At work we have it set as an external repository in our project. So it gets pulled every time we update. I've gotten complaints fro the others on the project at times. Dave From srbaker at pobox.com Fri May 12 16:57:22 2006 From: srbaker at pobox.com (Steven R. Baker) Date: Fri, 12 May 2006 13:57:22 -0700 Subject: [Rspec-devel] Subversion Movage In-Reply-To: <42916979-C6CB-4598-B520-B4442C75AC89@daveastels.com> References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> <42916979-C6CB-4598-B520-B4442C75AC89@daveastels.com> Message-ID: <2F603436-1DC0-4DDE-87A4-5A0A213D4D2B@pobox.com> > > At work we have it set as an external repository in our project. So > it gets pulled every time we update. I've gotten complaints fro the > others on the project at times. > We have the same setup here, and no complaints besides occasional slowness. If we cared about speed, though, we'd probably not be using Subversion. ;) -Steven From dastels at daveastels.com Fri May 12 17:13:11 2006 From: dastels at daveastels.com (David Astels) Date: Fri, 12 May 2006 18:13:11 -0300 Subject: [Rspec-devel] Subversion Movage In-Reply-To: <2F603436-1DC0-4DDE-87A4-5A0A213D4D2B@pobox.com> References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> <42916979-C6CB-4598-B520-B4442C75AC89@daveastels.com> <2F603436-1DC0-4DDE-87A4-5A0A213D4D2B@pobox.com> Message-ID: On 12-May-06, at 5:57 PM, Steven R. Baker wrote: >> >> At work we have it set as an external repository in our project. So >> it gets pulled every time we update. I've gotten complaints fro the >> others on the project at times. >> > > We have the same setup here, and no complaints besides occasional > slowness. That's fine then... as long as we can hook trac up to it. Dave From aslak.hellesoy at gmail.com Sun May 14 06:15:17 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 14 May 2006 12:15:17 +0200 Subject: [Rspec-devel] Subversion Movage In-Reply-To: References: <766CCC08-B731-486C-B615-A13D0C5F9155@pobox.com> <1DBB5FC1-F8E4-4A30-B8AA-2AF416050D63@daveastels.com> <062D040E-0433-416F-8D18-23498D7E0130@pobox.com> <42916979-C6CB-4598-B520-B4442C75AC89@daveastels.com> <2F603436-1DC0-4DDE-87A4-5A0A213D4D2B@pobox.com> Message-ID: <8d961d900605140315k243183f0o7063bed91f8fe32a@mail.gmail.com> On 5/12/06, David Astels wrote: > > On 12-May-06, at 5:57 PM, Steven R. Baker wrote: > > >> > >> At work we have it set as an external repository in our project. So > >> it gets pulled every time we update. I've gotten complaints fro the > >> others on the project at times. > >> > > > > We have the same setup here, and no complaints besides occasional > > slowness. > I have never experienced any problems with rubyforge except the file permissions issue which now seems to be ok. > That's fine then... as long as we can hook trac up to it. > Trac needs access to a local SVN filesystem So the only way to serve up a remote svn in trac is to use an SVK mirror (which also needs to be synched regularly and automtically). For more info see http://projects.edgewall.com/trac/wiki/TracFaq#can-i-use-trac-with-a-remote-subversion-repository Aslak > Dave > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Mon May 15 19:06:11 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Mon, 15 May 2006 18:06:11 -0500 Subject: [Rspec-devel] -s not working Message-ID: <8d961d900605151606u1fba2cc1j4466b79870191d28@mail.gmail.com> hi, just got back from holiday and decided to try out the new -s option (without looking at how it's implemented): The --help option gives very little info - I decided to try: ruby examples/bdd_framework_spec.rb -s 'should be adopted quickly' 0 contexts, 0 specifications, 0 failures This should have resulted in an error message saying something like "couldn't find spec" Then I took a really wild guess: ruby examples/bdd_framework_spec.rb -s 'BDD framework should be adopted quickly' 1 context, 1 specification, 0 failures I wouldn't expect the average user to grok that. Further, the website doco doesn't document this feature at all. Aslak From Keith.Hodges at warwick.ac.uk Mon May 15 21:45:44 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Tue, 16 May 2006 02:45:44 +0100 Subject: [Rspec-devel] innovations In-Reply-To: <44649182.4080709@warwick.ac.uk> References: <445C7E0A.5@warwick.ac.uk> <57c63afe0605060516u2be247f8ua39d3d278e04a753@mail.gmail.com> <44649182.4080709@warwick.ac.uk> Message-ID: <44692EC8.9020400@warwick.ac.uk> Dear rspec(ted) folk, I have added a couple of experimental features to spec.js and I wondered what you thought (given that Dave's previous feedback had such a radical impact last time around) 1. in a context setUp function any calls to other contexts invoke their setUp function too. This allows a context to call other contexts. e.g. context("A stack with one item").setUp= function() { context("A new stack") stack.push( "one item" ) } ----- 2. allow a context to include markPointWhere( ) items. e.g. define context like so: context( "typical stack use" ).setUp= function() { stack= new Stack() markPointWhere( 'stack instanciated' ) stack.push( 'one item' ) markPointWhere( one item is pushed onto empty stack ) } use like so: context( "typical stack use", "stack instanciated" ) or even perhaps: context( "typical stack use to point where stack instanciated" ) --- any thoughts? Keith Send instant messages to your online friends http://uk.messenger.yahoo.com From Keith.Hodges at warwick.ac.uk Tue May 16 18:00:29 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Tue, 16 May 2006 23:00:29 +0100 Subject: [Rspec-devel] innovations Message-ID: <446A4B7D.1080500@warwick.ac.uk> Eric Hodel wrote: > Please use the "reply" button in your mailer only when you want to > respond to existing threads and the "new" button to create new emails. > > When you use the reply button to create new messages you end up > hijacking threads which is frowned upon. thanks for the feedback. Keith Send instant messages to your online friends http://uk.messenger.yahoo.com From dchelimsky at gmail.com Tue May 16 18:10:40 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 16 May 2006 18:10:40 -0400 Subject: [Rspec-devel] -s not working In-Reply-To: <8d961d900605151606u1fba2cc1j4466b79870191d28@mail.gmail.com> References: <8d961d900605151606u1fba2cc1j4466b79870191d28@mail.gmail.com> Message-ID: <57c63afe0605161510o20ca54f3jdf7b6be854fb0a84@mail.gmail.com> I'll update the docs, but first - how would you want to see this work? We could just use the spec, but there could be name conflicts. I guess we could just run all the specs with that spec name, but then you might end up w/ object in state 1 - should do A when tickled object in state 2 - should do A when tickled etc. Other options would be to accept any of the following: "context" "context - spec" "spec" then let rspec run whatever it finds that it think matches. Thoughts? On 5/15/06, aslak hellesoy wrote: > hi, > > just got back from holiday and decided to try out the new -s option > (without looking at how it's implemented): > > The --help option gives very little info - I decided to try: > > ruby examples/bdd_framework_spec.rb -s 'should be adopted quickly' > 0 contexts, 0 specifications, 0 failures > > This should have resulted in an error message saying something like > "couldn't find spec" > > Then I took a really wild guess: > > ruby examples/bdd_framework_spec.rb -s 'BDD framework should be adopted quickly' > 1 context, 1 specification, 0 failures > > I wouldn't expect the average user to grok that. Further, the website > doco doesn't document this feature at all. > > Aslak > > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue May 16 21:05:33 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 16 May 2006 20:05:33 -0500 Subject: [Rspec-devel] -s not working In-Reply-To: <57c63afe0605161510o20ca54f3jdf7b6be854fb0a84@mail.gmail.com> References: <8d961d900605151606u1fba2cc1j4466b79870191d28@mail.gmail.com> <57c63afe0605161510o20ca54f3jdf7b6be854fb0a84@mail.gmail.com> Message-ID: <8d961d900605161805h33a07ae1kc6a4f04c27c9be8a@mail.gmail.com> On 5/16/06, David Chelimsky wrote: > I'll update the docs, but first - how would you want to see this work? > We could just use the spec, but there could be name conflicts. I guess > we could just run all the specs with that spec name, but then you > might end up w/ > > object in state 1 > - should do A when tickled > > object in state 2 > - should do A when tickled > > etc. Other options would be to accept any of the following: > > "context" > "context - spec" > "spec" > > then let rspec run whatever it finds that it think matches. > i think rspec should try to be smart, have a simple ui and give intelligent feedback when it can't do anything. in more formal (bdd story format) words: (as a [role] i want a [feature] so that [benefit]) as a rspec user i want a single option to filter out what context and/or specifications i want to run. so that i don't have to read the docs when i want to run a subset of my specs. acceptance criteria: given: context 'foo' do specify 'bar' do end end context 'mooky' do specify 'bar' do end end when: spec -s bar then: rspec runs 'foo bar' and 'mooky bar' when: spec -s 'foo bar' then: rspec runs 'foo bar' when: spec -s 'foo' then: rspec runs 'foo bar' when: spec -s cow then: rspec tells me there was no context or spec with the name 'cow' wdyt? > Thoughts? > > On 5/15/06, aslak hellesoy wrote: > > hi, > > > > just got back from holiday and decided to try out the new -s option > > (without looking at how it's implemented): > > > > The --help option gives very little info - I decided to try: > > > > ruby examples/bdd_framework_spec.rb -s 'should be adopted quickly' > > 0 contexts, 0 specifications, 0 failures > > > > This should have resulted in an error message saying something like > > "couldn't find spec" > > > > Then I took a really wild guess: > > > > ruby examples/bdd_framework_spec.rb -s 'BDD framework should be adopted quickly' > > 1 context, 1 specification, 0 failures > > > > I wouldn't expect the average user to grok that. Further, the website > > doco doesn't document this feature at all. > > > > Aslak > > > > _______________________________________________ > > 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 Tue May 16 22:04:00 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Tue, 16 May 2006 22:04:00 -0400 Subject: [Rspec-devel] -s not working In-Reply-To: <8d961d900605161805h33a07ae1kc6a4f04c27c9be8a@mail.gmail.com> References: <8d961d900605151606u1fba2cc1j4466b79870191d28@mail.gmail.com> <57c63afe0605161510o20ca54f3jdf7b6be854fb0a84@mail.gmail.com> <8d961d900605161805h33a07ae1kc6a4f04c27c9be8a@mail.gmail.com> Message-ID: <57c63afe0605161904m78f12312o388bceed01e4919@mail.gmail.com> On 5/16/06, aslak hellesoy wrote: > On 5/16/06, David Chelimsky wrote: > > > > etc. Other options would be to accept any of the following: > > > > "context" > > "context - spec" > > "spec" > > > > then let rspec run whatever it finds that it think matches. > > > > i think rspec should try to be smart, have a simple ui and give > intelligent feedback when it can't do anything. in more formal (bdd > story format) words: (as a [role] i want a [feature] so that > [benefit]) > > > as a rspec user > i want a single option to filter out what context and/or > specifications i want to run. > so that i don't have to read the docs when i want to run a subset of my specs. > > acceptance criteria: > > given: > > context 'foo' do > specify 'bar' do > end > end > > context 'mooky' do > specify 'bar' do > end > end > > when: > spec -s bar > > then: > rspec runs 'foo bar' and 'mooky bar' > > when: > spec -s 'foo bar' > > then: > rspec runs 'foo bar' > > when: > spec -s 'foo' > > then: > rspec runs 'foo bar' > > when: > spec -s cow > > then: > rspec tells me there was no context or spec with the name 'cow' > > > wdyt? That's what I had in mind w/ the suggestion above. I'll set it up. From aslak.hellesoy at gmail.com Thu May 18 14:41:37 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu, 18 May 2006 13:41:37 -0500 Subject: [Rspec-devel] test2rspec (in rSpec v0.5.4) In-Reply-To: <533048b70605181024l3930874eg54d98dbfc900c82d@mail.gmail.com> References: <533048b70605181024l3930874eg54d98dbfc900c82d@mail.gmail.com> Message-ID: <8d961d900605181141n315a87dg181078ce60d29947@mail.gmail.com> I've created a ticket for this: http://rubyforge.org/tracker/index.php?func=detail&aid=4512&group_id=797&atid=3149 Cheers, Aslak On 5/18/06, DeeJay wrote: > > > FAO: rSpec developer team > > Greetings > > according to > > http://rspec.rubyforge.org/tools/test2rspec.html > > the command line syntax for test2rspec is > > test2rspec SRC [DEST] > > and "If DEST is not supplied, output is sent to STDOUT" > > That is NOT the case on my Windows installation, WinXPpro-SP2 with Ruby > 1.8.4 via > the OneClickInstaller and rSpec 0.5.4 via RubyGems. > > > > > H:\RubyExpt>test2rspec petestfoo.rb > can't convert nil into String > [ ** error trace suppressed **] > > Usage: test2rspec [options] SRC [DEST] > > -h, --help Show this message > > > Easily 'fixed' by specifying an output file, but a bit bewildering to a > beginner, who was looking in the test.rb input file for an error! :-( > > Thanks for your efforts on rSpec and friends. I am looking forward to the > integration with ZenTest and fellow-travellers. > > DeeJay, Leicester, UK > > > > From dchelimsky at gmail.com Sat May 20 01:10:25 2006 From: dchelimsky at gmail.com (David Chelimsky) Date: Sat, 20 May 2006 01:10:25 -0400 Subject: [Rspec-devel] -s not working In-Reply-To: <57c63afe0605161904m78f12312o388bceed01e4919@mail.gmail.com> References: <8d961d900605151606u1fba2cc1j4466b79870191d28@mail.gmail.com> <57c63afe0605161510o20ca54f3jdf7b6be854fb0a84@mail.gmail.com> <8d961d900605161805h33a07ae1kc6a4f04c27c9be8a@mail.gmail.com> <57c63afe0605161904m78f12312o388bceed01e4919@mail.gmail.com> Message-ID: <57c63afe0605192210o1371e513wc18afc2fe0c03308@mail.gmail.com> I've committed changes to svn to support these formats: "context" "context spec" "spec" Still need to add the following: - message when no specs are found to match - documentation Cheers, David On 5/16/06, David Chelimsky wrote: > On 5/16/06, aslak hellesoy wrote: > > On 5/16/06, David Chelimsky wrote: > > > > > > etc. Other options would be to accept any of the following: > > > > > > "context" > > > "context - spec" > > > "spec" > > > > > > then let rspec run whatever it finds that it think matches. > > > > > > > i think rspec should try to be smart, have a simple ui and give > > intelligent feedback when it can't do anything. in more formal (bdd > > story format) words: (as a [role] i want a [feature] so that > > [benefit]) > > > > > > as a rspec user > > i want a single option to filter out what context and/or > > specifications i want to run. > > so that i don't have to read the docs when i want to run a subset of my specs. > > > > acceptance criteria: > > > > given: > > > > context 'foo' do > > specify 'bar' do > > end > > end > > > > context 'mooky' do > > specify 'bar' do > > end > > end > > > > when: > > spec -s bar > > > > then: > > rspec runs 'foo bar' and 'mooky bar' > > > > when: > > spec -s 'foo bar' > > > > then: > > rspec runs 'foo bar' > > > > when: > > spec -s 'foo' > > > > then: > > rspec runs 'foo bar' > > > > when: > > spec -s cow > > > > then: > > rspec tells me there was no context or spec with the name 'cow' > > > > > > wdyt? > > That's what I had in mind w/ the suggestion above. I'll set it up. > From itsme213 at hotmail.com Sat May 27 23:50:08 2006 From: itsme213 at hotmail.com (itsme213) Date: Sat, 27 May 2006 22:50:08 -0500 Subject: [Rspec-devel] Failure messages - customize per "should" assertion Message-ID: Is there a way to customize the failure message for each "should" assertion? e.g. I have specify 'every activity should have an output' do Activity.instances.each {|a| a.outputs.should_not_be_empty } end I get: 1) ExpectationNotMetError in 'MAp object graph every activity should have an output' [] should not be empty I would like to customize the failure message based on the activity |a|. Is this possible? Should it be? Thanks! From itsme213 at hotmail.com Sun May 28 00:24:05 2006 From: itsme213 at hotmail.com (itsme213) Date: Sat, 27 May 2006 23:24:05 -0500 Subject: [Rspec-devel] verbose mode? Message-ID: Would it be reasonable to have a 'verbose' mode in which the "..." are interleaved with the corresponding context + spec text? Output might look like: context 1 spec 1 ... spec 2 ... spec 3 ..... context 2 spec 4 .. I am showing a "." for each "should", as I think in verbose mode this would be better than just a "." for each spec including assertion-less specs e.g. it would shows specs that pass simply because they have no assertions. Thanks for a great piece of work! From aslak.hellesoy at gmail.com Sun May 28 01:50:03 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 28 May 2006 00:50:03 -0500 Subject: [Rspec-devel] Failure messages - customize per "should" assertion In-Reply-To: References: Message-ID: <8d961d900605272250n30b5c7bdg9f50cde93e802b10@mail.gmail.com> On 5/27/06, itsme213 wrote: > Is there a way to customize the failure message for each "should" assertion? > > e.g. I have > > specify 'every activity should have an output' do > Activity.instances.each {|a| a.outputs.should_not_be_empty } > end > > I get: > > 1) > ExpectationNotMetError in 'MAp object graph every activity should have an > output' > [] should not be empty > > > I would like to customize the failure message based on the activity |a|. > Each failure message consists of 2 parts: part 1: This is the context name followed by the specification name. This purpose is to communicate the high level information first (assuming the programmer named the properly). This should read as a sentence. part 2: This is the failed should_*. The purpose is to communicate the detailed information about it, such as why something failed and where (line number). > Is this possible? Should it be? > If you're referring to part 1 - yes. Just change the words. If you're referring to part 2 - no. Can you provide a code example of how you would like to customize error messages? Why would you like to customize them? Aslak > Thanks! > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Sun May 28 01:52:23 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sun, 28 May 2006 00:52:23 -0500 Subject: [Rspec-devel] verbose mode? In-Reply-To: References: Message-ID: <8d961d900605272252l5503ca06q514728d54c8b63c@mail.gmail.com> On 5/27/06, itsme213 wrote: > Would it be reasonable to have a 'verbose' mode in which the "..." are > interleaved with the corresponding context + spec text? Output might look > like: > > context 1 > spec 1 ... > spec 2 ... > spec 3 ..... > context 2 > spec 4 .. > > I am showing a "." for each "should", as I think in verbose mode this would > be better than just a "." for each spec including assertion-less specs e.g. > it would shows specs that pass simply because they have no assertions. > That's an interesting feature. Please post a feature request at Rubyforge so we don't forget. http://rubyforge.org/tracker/?group_id=797 Aslak > Thanks for a great piece of work! > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From itsme213 at hotmail.com Sun May 28 11:01:44 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 10:01:44 -0500 Subject: [Rspec-devel] Failure messages - customize per "should"assertion References: <8d961d900605272250n30b5c7bdg9f50cde93e802b10@mail.gmail.com> Message-ID: From: "aslak hellesoy" >> Is there a way to customize the failure message for each "should" >> assertion? >> >> e.g. I have >> >> context 'object graph' >> specify 'every activity should have an output' do >> Activity.instances.each {|a| a.outputs.should_not_be_empty } >> end Note that the "should" is separated from the "specify" by some logic (in this case, a loop). In such cases the "should" string may not be specific enough for a given failure. >> > Can you provide a code example of how you would like to customize > error messages? Yes. Instead of this: 1) ExpectationNotMetError in 'object graph every activity should have an output' [] should not be empty I would like to see some this: ExpectationNotMetError in 'object graph every activity should have an output' ACTIVITY A72 [] should not be empty Possible API for this passing in a block that will yield the detailed string: context 'object graph' specify 'every activity should have an output' do Activity.instances.each {|a| a.outputs.should_not_be_empty {a.name} } end > Why would you like to customize them? In cases where the "should" is separated from the "specify" by some logic (in this case, a loop), the "should" string may not be specific enough for a given failure. Btw, this request may be related to nested (or otherwise structured) contexts, which may be a better and more general solution if it can be kept simple. I will post that separately. Thanks! From itsme213 at hotmail.com Sun May 28 12:12:14 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 11:12:14 -0500 Subject: [Rspec-devel] context could yield an object, and be nested Message-ID: This reflects my quite-incomplete understanding of rspec, please excuse if entirely off-base :( Context sets up the state for several Specify blocks, each of which has many Shoulds. Setup has the executable code to establish context state. It is executed once prior to each Specify. (TearDown is its complement). There is currently no way to relate a Context to other Contexts. However, it is often natural to think of a Context as related to other Contexts in a tree structure, where the parent represents some form of a pre-requisite context (e.g. when contexts represent states in some state sequence, then parent might be an earlier state; or when contexts represent an object in an object graph, then parent might be a container object). Proposal: Allow contexts to be nested. Setup can either establish the context as a side-effect (as it currently does), or return it as an object, or both. The block of a nested Context is passed the object returned by the parent Context's Setup. The block of each Specify, Setup, and TearDown is similarly passed the object returned by the parent Context's Setup. context :A do setup do 1 end specify :s1 do |c| puts c #=> 1 end context :A1 do |c| puts c #=> 1 setup do |c| puts c #=> 1 2 end specify :s2 do |c| puts c #=> 2 end end end Note: once Specify and Context takes a parent context argument, it might make sense for the description string for the Specify to somehow have access to that context object. Setup for a Context is still executed once prior to each Specify for that Context. This should probably apply transitively to all parent's Setup. That said, it would be useful to have Context#start_once (and #end_once) methods whose blocks are guaranteed executed exactly once before the first Specify & Setup & nested Context (after the last Specify & nested Context & TearDown, respectively) in that Context. From itsme213 at hotmail.com Sun May 28 12:33:23 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 11:33:23 -0500 Subject: [Rspec-devel] Failure messages - customize per "should"assertion References: <8d961d900605272250n30b5c7bdg9f50cde93e802b10@mail.gmail.com> Message-ID: > part 2: This is the failed should_*. The purpose is to communicate the > detailed information about it, such as why something failed and where > (line number). The line_number is necessary not always sufficient. In the same spirit as generating user-readable narrative specs from spec, we might aim for user-readable spec-failure reports, which could need more dynamic context than a static "specify" string can provide. From dastels at daveastels.com Sun May 28 15:39:32 2006 From: dastels at daveastels.com (David Astels) Date: Sun, 28 May 2006 16:39:32 -0300 Subject: [Rspec-devel] context could yield an object, and be nested In-Reply-To: References: Message-ID: On 28-May-06, at 1:12 PM, itsme213 wrote: > However, it is often natural to think of a Context as related to other > Contexts in a tree structure, where the parent represents some form > of a > pre-requisite context (e.g. when contexts represent states in some > state > sequence, then parent might be an earlier state; or when contexts > represent > an object in an object graph, then parent might be a container > object). > > Proposal: Allow contexts to be nested. Setup can either establish the > context as a side-effect (as it currently does), or return it as an > object, > or both. The block of a nested Context is passed the object > returned by the > parent Context's Setup. The block of each Specify, Setup, and > TearDown is > similarly passed the object returned by the parent Context's Setup. IMHO this is would be a source of complexity & confusion. 1) The more distributed the context and/or specifications are, the more work it is to understand exactly what is going on. 2) Both contexts and specification should be as clear and simple as possible. Dave From dastels at daveastels.com Sun May 28 15:43:39 2006 From: dastels at daveastels.com (David Astels) Date: Sun, 28 May 2006 16:43:39 -0300 Subject: [Rspec-devel] Failure messages - customize per "should"assertion In-Reply-To: References: <8d961d900605272250n30b5c7bdg9f50cde93e802b10@mail.gmail.com> Message-ID: <32831DA7-DDF3-42BB-B667-58CDFD8D71E7@daveastels.com> On 28-May-06, at 1:33 PM, itsme213 wrote: >> part 2: This is the failed should_*. The purpose is to communicate >> the >> detailed information about it, such as why something failed and where >> (line number). > > The line_number is necessary not always sufficient. In the same > spirit as > generating user-readable narrative specs from spec, we might aim for > user-readable spec-failure reports, which could need more dynamic > context > than a static "specify" string can provide. Specifications should be as simple and minimalistic as possible. I.e. having as few expectations as is possible, ideally a single one. Thos expectations should be simple & clear. Knowing the lin number should provide as much information as you need to know what the failure is. If it doesn't, then it is likely that the specification and/or expectation is too complex, and you should consider makign it simpler. It is possible that you are working at too high a level of granularity/abstraction. Dave From itsme213 at hotmail.com Sun May 28 19:19:56 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 18:19:56 -0500 Subject: [Rspec-devel] context could yield an object, and be nested References: Message-ID: > IMHO this is would be a source of complexity & confusion. > > 1) The more distributed the context and/or specifications are, the > more work it is to understand exactly what is going on. > > 2) Both contexts and specification should be as clear and simple as > possible. I agree with both these. Would you agree with this third principle? 3) Both contexts and specifications should not be duplicated unnecessarily. For example, a home security spec: In an empty home - the security system should be enabled When a door is opened - the system should beep - the display should highlight the door When the password is entered on time - the beeping should stop - the system should be disabled - the display should highlight the door When the password is not entered on time - the alarm should go off - the monitoring company should be notified I think the "-" lines are specs, others are contexts. Would this be reasonable? Would structuring the spec like this contradict principles #1,2,3? Thanks. From Keith.Hodges at warwick.ac.uk Sun May 28 20:08:31 2006 From: Keith.Hodges at warwick.ac.uk (Keith Hodges) Date: Mon, 29 May 2006 01:08:31 +0100 Subject: [Rspec-devel] Failure messages - customize per "should"assertion In-Reply-To: References: <8d961d900605272250n30b5c7bdg9f50cde93e802b10@mail.gmail.com> Message-ID: <447A3B7F.7050104@warwick.ac.uk> Dear "itsme", In my experimental javascript adaptation of rspec I included the ability to construct and dissect contexts. I particularly like the ability to use a context up to a specified point. I think it may improve clarity and reduce repeated code but I have not had any feedback on this as yet so I would be interested to hear what you think. Keith original message follows: > I have added a couple of experimental features to spec.js and I wondered > what you thought (given that Dave's previous feedback had such a radical > impact last time around) > > 1. in a context setUp function any calls to other contexts invoke their > setUp function too. This allows a context to call other contexts. > > e.g. > > context("A stack with one item").setUp= function() > { > context("A new stack") > stack.push( "one item" ) > } > > ----- > > 2. allow a context to include markPointWhere( ) items. e.g. > > define context like so: > > context( "typical stack use" ).setUp= function() > { > stack= new Stack() > markPointWhere( 'stack instanciated' ) > > stack.push( 'one item' ) > markPointWhere( one item is pushed onto empty stack ) > } > > use like so: > > context( "typical stack use", "stack instanciated" ) > > or even perhaps: > > context( "typical stack use, to point where, stack instanciated" ) > > --- > > any thoughts? > > Keith > Send instant messages to your online friends http://uk.messenger.yahoo.com From itsme213 at hotmail.com Sun May 28 20:16:45 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 19:16:45 -0500 Subject: [Rspec-devel] use case for: setup_once, teardown_once Message-ID: Setup and teardown are called once for each specify. Sometimes the setup can be very expensive (e.g. establish a ssh or ftp session) and the number of specs large. context 'Remote Site' do require 'net/ftp' setup do @ftp = Net::FTP.new(...) end teardown do @ftp.close end specify 'remote spec 1' do @ftp.foo end specify 'remote spec 2' do @ftp.bar end specify 'remote spec 999' do @ftp.baz end end In such cases it would be quite useful to have a 'once' version. Otherwise one might end up munging separate specs into one to avoid the performance overhead. I believe there are other non-performance related use cases for such a facility as well, where it would also helps keep specs separate and simple. Of course, the user would have to be careful about interactions across specs in the same context. Thoughts? From itsme213 at hotmail.com Sun May 28 21:14:31 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 20:14:31 -0500 Subject: [Rspec-devel] SpecTask with rake Message-ID: Any idea what I am doing wrong here? When I try a rakefile: ------------------- require 'rake' require 'spec/rake/spectask' desc "spec" Spec::Rake::SpecTask.new do |t| t.libs << "spec" t.spec_files = FileList['spec/**/*_spec.rb'] end ------------------- I get: C:>rake spec (in C:) ruby -Ilib;spec "c:/ruby/lib/ruby/gems/1.8/gems/rspec-0.5.4/lib/spec/rake/../../../bin/spec" Usage: spec [options] (FILE|DIRECTORY)+ -b, --backtrace Output full backtrace -f, --format FORMAT Output format (specdoc|s|rdoc|r) -d, --dry-run Don't execute specs -s, --spec SPECIFICATION_NAME Execute a single specification -v, --version Show version -h, --help Show this message ------------------- If the spectask integration is not working yet, how can I directly process my spec file in a normal rake task? Thanks! From itsme213 at hotmail.com Sun May 28 21:26:21 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 20:26:21 -0500 Subject: [Rspec-devel] Failure messages - customize per "should"assertion References: <8d961d900605272250n30b5c7bdg9f50cde93e802b10@mail.gmail.com> <447A3B7F.7050104@warwick.ac.uk> Message-ID: Hi Keith, > In my experimental javascript adaptation of rspec I included the ability > to construct and dissect contexts. I particularly like the ability to > use a context up to a specified point. I think it may improve clarity > and reduce repeated code but I have not had any feedback on this as yet > so I would be interested to hear what you think. I like your ability to relate contexts (have not yet looked at your version of specs). I'm not as sure about the pros/cons of pointing at arbitrary named points within a context. Does it let you do things that you could not do with finer-grained related contexts e.g. "instantiated" and "one item pushed"? Is it a lot more convenient with named points in one setup function compared to separate contexts? Cheers ... From dastels at daveastels.com Sun May 28 21:27:36 2006 From: dastels at daveastels.com (David Astels) Date: Sun, 28 May 2006 22:27:36 -0300 Subject: [Rspec-devel] context could yield an object, and be nested In-Reply-To: References: Message-ID: On 28-May-06, at 8:19 PM, itsme213 wrote: >> IMHO this is would be a source of complexity & confusion. >> >> 1) The more distributed the context and/or specifications are, the >> more work it is to understand exactly what is going on. >> >> 2) Both contexts and specification should be as clear and simple as >> possible. > > I agree with both these. Would you agree with this third principle? > > 3) Both contexts and specifications should not be duplicated > unnecessarily. I would accept duplication for enhanced clarity. This is not production code, clarity and understandability has very high priority. In my experience, refactoring this code too aggressively negatively impacts understandability. Dave From dastels at daveastels.com Sun May 28 21:30:23 2006 From: dastels at daveastels.com (David Astels) Date: Sun, 28 May 2006 22:30:23 -0300 Subject: [Rspec-devel] use case for: setup_once, teardown_once In-Reply-To: References: Message-ID: On 28-May-06, at 9:16 PM, itsme213 wrote: > Setup and teardown are called once for each specify. > > Sometimes the setup can be very expensive (e.g. establish a ssh or ftp > session) and the number of specs large. This should never be done. You never want your specifications dependant on a) externsl, b) expensive, and c) nondeterministic/ uncontrollable resources. This is where you would use the mocking framework to mock the ssh/ftp interface. Dave From itsme213 at hotmail.com Sun May 28 23:06:52 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 22:06:52 -0500 Subject: [Rspec-devel] context could yield an object, and be nested References: Message-ID: > I would accept duplication for enhanced clarity. Fair enough. Would you say this one is not clear? In an empty home - the security system should be enabled When a door is opened - the system should beep - the display should highlight the door When the password is entered on time - the beeping should stop - the system should be disabled - the display should highlight the door When the password is not entered on time - the alarm should go off - the monitoring company should be notified How would you suggest this one be written in rspec? Thanks. From itsme213 at hotmail.com Sun May 28 23:21:53 2006 From: itsme213 at hotmail.com (itsme213) Date: Sun, 28 May 2006 22:21:53 -0500 Subject: [Rspec-devel] use case for: setup_once, teardown_once References: Message-ID: From: "David Astels" >> Sometimes the setup can be very expensive (e.g. establish a ssh or ftp >> session) and the number of specs large. > > This should never be done. You never want your specifications > dependant on a) externsl, b) expensive, and c) nondeterministic/ > uncontrollable resources. Good point, thanks. I do need to use mocks more. > This is where you would use the mocking > framework to mock the ssh/ftp interface. In this case I was actually using spec to specify some explicit requirements about the (remote) results of a (remote) deployment, to say things like: - the remote directory structure should satisfy ... - remote file time stamps should be ... - remote access controls should be ... How would mocks help with this? Or is this not an appropriate thing to specify? Thanks. From sl4mmy at zerosphere.org Mon May 29 01:24:10 2006 From: sl4mmy at zerosphere.org (Kent R. Spillner) Date: Mon, 29 May 2006 00:24:10 -0500 Subject: [Rspec-devel] Mock the krufty bits, don't complicate the framework (was Re: use case for: setup_once, teardown_once) In-Reply-To: References: Message-ID: <447A857A.9080808@zerosphere.org> Hi, "itsme213"- itsme213 wrote: > Sometimes the setup can be very expensive (e.g. establish a ssh or ftp > session) and the number of specs large. Use mocks instead. > In an empty home > - the security system should be enabled > When a door is opened > - the system should beep > - the display should highlight the door > When the password is entered on time > - the beeping should stop > - the system should be disabled > - the display should highlight the door > When the password is not entered on time > - the alarm should go off > - the monitoring company should be notified > > How would you suggest this one be written in rspec? Using mocks (mock home, mock open door...) > - the remote directory structure should satisfy ... > - remote file time stamps should be ... > - remote access controls should be ... > > How would mocks help with this? Refer to what David wrote: >> This should never be done. You never want your specifications >> dependant on a) externsl, b) expensive, and c) nondeterministic/ >> uncontrollable resources. So, mocks would help by eliminating dependecies on a) external, b) expensive, and c) nondeterministic/uncontrollable resources. That's win-win-win, dude! :D Best, Kent From dastels at daveastels.com Mon May 29 06:46:12 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 29 May 2006 07:46:12 -0300 Subject: [Rspec-devel] context could yield an object, and be nested In-Reply-To: References: Message-ID: <2B7798EE-84B6-4519-BFD0-CF2590DC51A8@daveastels.com> On 29-May-06, at 12:06 AM, itsme213 wrote: >> I would accept duplication for enhanced clarity. > > Fair enough. Would you say this one is not clear? > > In an empty home > - the security system should be enabled > When a door is opened > - the system should beep > - the display should highlight the door > When the password is entered on time > - the beeping should stop > - the system should be disabled > - the display should highlight the door > When the password is not entered on time > - the alarm should go off > - the monitoring company should be notified This looks fine, but what does the code look like? > How would you suggest this one be written in rspec? > In an empty home > - the security system should be enabled > When a the system is triggered > - the system should beep > - the display should highlight the door > When the password is entered on time after the system is triggered > - the beeping should stop > - the system should be disabled > - the display should highlight the door > When the password is not entered on time after the system is triggered > - the alarm should go off > - the monitoring company should be notified From itsme213 at hotmail.com Mon May 29 11:50:55 2006 From: itsme213 at hotmail.com (itsme213) Date: Mon, 29 May 2006 10:50:55 -0500 Subject: [Rspec-devel] context could yield an object, and be nested References: <2B7798EE-84B6-4519-BFD0-CF2590DC51A8@daveastels.com> Message-ID: From: "David Astels" >> In an empty home >> - the security system should be enabled > >> When a the system is triggered >> - the system should beep >> - the display should highlight the door > >> When the password is entered on time after the system is triggered >> - the beeping should stop >> - the system should be disabled >> - the display should highlight the door > >> When the password is not entered on time after the system is triggered >> - the alarm should go off >> - the monitoring company should be notified Hmm. If I understand your reasoning, then why not go the logical next step and do further un-distribute as follows: ------------ When the password is entered on time after the system is triggered the beeping should stop When the password is entered on time after the system is triggered the system should be disabled When the password is entered on time after the system is triggered the display should highlight the door ------------ It seems to me that nested contexts and r-spec's context-specification separation are both doing very similar "distribution". Btw, I am just trying to understand your reasoning here. Thanks. From itsme213 at hotmail.com Mon May 29 11:55:22 2006 From: itsme213 at hotmail.com (itsme213) Date: Mon, 29 May 2006 10:55:22 -0500 Subject: [Rspec-devel] Mock the krufty bits, don't complicate the framework (was Re: use case for: setup_once, teardown_once) References: <447A857A.9080808@zerosphere.org> Message-ID: Hi Kent, >> How would you suggest this one be written in rspec? > > Using mocks (mock home, mock open door...) I had meant this as an example of nested contexts, not about performance or mocks. Even after mocking things out there is still the question of how the contexts and specs are structured. > That's > win-win-win, dude! :D I agree. Thanks. From dastels at daveastels.com Mon May 29 12:37:07 2006 From: dastels at daveastels.com (David Astels) Date: Mon, 29 May 2006 13:37:07 -0300 Subject: [Rspec-devel] context could yield an object, and be nested In-Reply-To: References: <2B7798EE-84B6-4519-BFD0-CF2590DC51A8@daveastels.com> Message-ID: <9FD72563-9E8B-4A8E-86BC-BD54B5B4DC9E@daveastels.com> On 29-May-06, at 12:50 PM, itsme213 wrote: > > Hmm. If I understand your reasoning, then why not go the logical > next step > and do further un-distribute as follows: > > ------------ > When the password is entered on time after the system is triggered the > beeping should stop > > When the password is entered on time after the system is triggered the > system should be disabled > > When the password is entered on time after the system is triggered the > display should highlight the door > ------------ The context in each of these is identical... so all 3 specs run in the same context. That's idea behind the context concept. It's not for removing/minimizing duplication, it's for providing a contained, cohesive environment for the contained specs to run in. > It seems to me that nested contexts and r-spec's context-specification > separation are both doing very similar "distribution". Yes, but in rSpec we stop at one level. Having hierarchical contexts confuses things... you have to look in several places to see what the "context" for a specific spec is, rather than just a single place. Dave From itsme213 at hotmail.com Mon May 29 14:36:16 2006 From: itsme213 at hotmail.com (itsme213) Date: Mon, 29 May 2006 13:36:16 -0500 Subject: [Rspec-devel] context could yield an object, and be nested References: <2B7798EE-84B6-4519-BFD0-CF2590DC51A8@daveastels.com> <9FD72563-9E8B-4A8E-86BC-BD54B5B4DC9E@daveastels.com> Message-ID: From: "David Astels" > Yes, but in rSpec we stop at one level. Having hierarchical contexts > confuses things... you have to look in several places to see what the > "context" for a specific spec is, rather than just a single place. But spec -f could re-create either the nested structure or a flattened version. I don't see how a nested outline structure is intrinsically less clear than the flat one. After all, a good specification has a good table of contents. When scaled up 100x the nested structure would work better than a flat one which put that structure in the names of the flattened contexts. "When the password is entered on time"..after.."the system is triggered" Is this line of thinking reasonable? Contradictory to rspec philosophy? If the latter I'll hush up :-) Thanks. From itsme213 at hotmail.com Tue May 30 15:13:18 2006 From: itsme213 at hotmail.com (itsme213) Date: Tue, 30 May 2006 14:13:18 -0500 Subject: [Rspec-devel] SpecTask with rake References: Message-ID: Anyone have SpecTask working in rake? Any idea what I am doing wrong here? Thanks. > Any idea what I am doing wrong here? When I try a rakefile: > > ------------------- > require 'rake' > require 'spec/rake/spectask' > > desc "spec" > Spec::Rake::SpecTask.new do |t| > t.libs << "spec" > t.spec_files = FileList['spec/**/*_spec.rb'] > end > > ------------------- > > I get: > C:>rake spec > (in C:) > ruby -Ilib;spec > "c:/ruby/lib/ruby/gems/1.8/gems/rspec-0.5.4/lib/spec/rake/../../../bin/spec" > Usage: spec [options] (FILE|DIRECTORY)+ > > -b, --backtrace Output full backtrace > -f, --format FORMAT Output format (specdoc|s|rdoc|r) > -d, --dry-run Don't execute specs > -s, --spec SPECIFICATION_NAME Execute a single specification > -v, --version Show version > -h, --help Show this message > > > ------------------- > > If the spectask integration is not working yet, how can I directly process > my spec file in a normal rake task? > From aslak.hellesoy at gmail.com Tue May 30 17:37:43 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 30 May 2006 16:37:43 -0500 Subject: [Rspec-devel] SpecTask with rake In-Reply-To: References: Message-ID: <8d961d900605301437h1f8c761bs95e04aec7a6a5327@mail.gmail.com> The FileList probably resolves to an empty set of files. Are you sure you have files that match the glob ('spec/**/*_spec.rb')? Also, what spec --version are you using? Aslak On 5/28/06, itsme213 wrote: > Any idea what I am doing wrong here? When I try a rakefile: > > ------------------- > require 'rake' > require 'spec/rake/spectask' > > desc "spec" > Spec::Rake::SpecTask.new do |t| > t.libs << "spec" > t.spec_files = FileList['spec/**/*_spec.rb'] > end > > ------------------- > > I get: > C:>rake spec > (in C:) > ruby -Ilib;spec > "c:/ruby/lib/ruby/gems/1.8/gems/rspec-0.5.4/lib/spec/rake/../../../bin/spec" > Usage: spec [options] (FILE|DIRECTORY)+ > > -b, --backtrace Output full backtrace > -f, --format FORMAT Output format (specdoc|s|rdoc|r) > -d, --dry-run Don't execute specs > -s, --spec SPECIFICATION_NAME Execute a single specification > -v, --version Show version > -h, --help Show this message > > > ------------------- > > If the spectask integration is not working yet, how can I directly process > my spec file in a normal rake task? > > Thanks! > _______________________________________________ > Rspec-devel mailing list > Rspec-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-devel > From aslak.hellesoy at gmail.com Tue May 30 17:38:23 2006 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Tue, 30 May 2006 16:38:23 -0500 Subject: [Rspec-devel] SpecTask with rake In-Reply-To: <8d961d900605301437h1f8c761bs95e04aec7a6a5327@mail.gmail.com> References: <8d961d900605301437h1f8c761bs95e04aec7a6a5327@mail.gmail.com> Message-ID: <8d961d900605301438i7d13b8b8pb7af4442d0e3be50@mail.gmail.com> On 5/30/06, aslak hellesoy wrote: > The FileList probably resolves to an empty set of files. Are you sure > you have files that match the glob ('spec/**/*_spec.rb')? > > Also, what spec --version are you using? > Never mind - I see from your backtrace that it's 0.5.4 > Aslak > > On 5/28/06, itsme213 wrote: > > Any idea what I am doing wrong here? When I try a rakefile: > > > > ------------------- > > require 'rake' > > require 'spec/rake/spectask' > > > > desc "spec" > > Spec::Rake::SpecTask.new do |t| > > t.libs << "spec" > > t.spec_files = FileList['spec/**/*_spec.rb'] > > end > > > > ------------------- > > > > I get: > > C:>rake spec > > (in C:) > > ruby -Ilib;spec > > "c:/ruby/lib/ruby/gems/1.8/gems/rspec-0.5.4/lib/spec/rake/../../../bin/spec" > > Usage: spec [options] (FILE|DIRECTORY)+ > > > > -b, --backtrace Output full backtrace > > -f, --format FORMAT Output format (specdoc|s|rdoc|r) > > -d, --dry-run Don't execute specs > > -s, --spec SPECIFICATION_NAME Execute a single specification > > -v, --version Show version > > -h, --help Show this message > > > > > > ------------------- > > > > If the spectask integration is not working yet, how can I directly process > > my spec file in a normal rake task? > > > > Thanks! > > _______________________________________________ > > Rspec-devel mailing list > > Rspec-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-devel > > > From itsme213 at hotmail.com Tue May 30 18:01:39 2006 From: itsme213 at hotmail.com (itsme213) Date: Tue, 30 May 2006 17:01:39 -0500 Subject: [Rspec-devel] SpecTask with rake References: <8d961d900605301437h1f8c761bs95e04aec7a6a5327@mail.gmail.com> Message-ID: Thanks Aslak. > The FileList probably resolves to an empty set of files. Are you sure > you have files that match the glob ('spec/**/*_spec.rb')? I had set up the rakefile in a working dir, with a subdir 'spec', and my x_spec.rb files in there, so I thought I had it right. But a breakpoint showed the task was running a different Dir.pwd. I reset it explicitly in the spec task and it now works fine. > Also, what spec --version are you using? 0.5.4. Thanks again. From noreply at rubyforge.org Sun May 28 12:16:10 2006 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 28 May 2006 12:16:10 -0400 Subject: [Rspec-devel] [ rspec-Feature Requests-4590 ] verbose mode Message-ID: <200605281616.k4SGGAa5005648@rubyforge.org> Feature Requests item #4590, was opened at 2006-05-28 12:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=4590&group_id=797 Category: None Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: verbose mode Initial Comment: Would it be reasonable to have a 'verbose' mode in which the "..." are interleaved with the corresponding context + spec text? Output might look like: context 1 spec 1 ... spec 2 ... spec 3 ..... context 2 spec 4 .. I am showing a "." for each "should", as I think in verbose mode this would be better than just a "." for each spec including assertion-less specs e.g. it would shows specs that pass simply because they have no assertions. Thanks for a great piece of work! ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3152&aid=4590&group_id=797