Re: [rspec-users] After upgrade to newest TM Bundle I get "Invalid char" error
Steffen, What ruby version do you have? i.e. /usr/bin/ruby -v -- Chad On Sep 14, 2009, at 2:32 PM, Steffen Hiller wrote: Hey, I finally upgraded from a rather old RSpec Textmate Bundle to the newest version. (master:efe49e) But when running any commands such as "Run Examples" or "Alternate File" I get: /usr/bin/ruby:1: Invalid char `\312' in expression /usr/bin/ruby:1: Invalid char `\376' in expression /usr/bin/ruby:1: Invalid char `\272' in expression /usr/bin/ruby:1: Invalid char `\276' in expression Anybody has any idea??? Using latest Textmate Version 1.5.8 (1509) and Max OS Leopard. Other Bundles still work fine. Reloaded Bundles + Restarted Textmate. Thanks! Steffen -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [RSpec] rcov and/or rexml bug?
Githubs recent gem builder changes have caused some issues with this. We are looking into it today in more detail. Pulling it down and manually building should definitely work in the meantime. -- Chad Humphries spicycode On Feb 13, 2009, at 4:01 AM, Fernando Perez wrote: You shouldn't have to clone and install rcov manually. Just do this: gem install spicycode-rcov --source http://gems.github.com It will install just like any other gem. Except it didn't work for me, the rcov binary doesn't get installed or is not defined properly. Is anyone else experiencing the same problem? -- Posted via http://www.ruby-forum.com/. ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] plans for cucumber
I have one question outside of rspec land in regards to cucumber.
I've used it with test unit, test spec, and rspec without issue.
Will it still be a relatively easy require to use on projects outside
of rspec? More specifically, is the plan to have it replace story
runner within rspec, or to replace it and stay a separate gem?
--
Chad
On Tue, Sep 23, 2008 at 8:44 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 4:21 AM, Ashley Moran
> <[EMAIL PROTECTED]> wrote:
>>
>> On 23 Sep 2008, at 02:35, David Chelimsky wrote:
>>
>>> This should work right now with both 'rake spec' and 'cucumber features'
>>
>> It does, but only as "cucumber features" if I do "cucumber
>> features/descriptions/xyz.feature" it doesn't find the the step file on it's
>> own.
>
> "the step file" assumes a one to one mapping of feature files to step
> files. I tend to reuse steps across features, so this has little value
> for me, personally. I think it is a constraint that might serve some
> people's needs well, but not everybody's.
>
>> Ben's TextMate Cucumber bundle reflects this, as it's "go to alternate file"
>> command creates steps one level down from the descriptions.
>>
>> Kyle's "story" command uses the structure stories/stories and stories/steps
>> so I'm used to working that way.
>
> While I appreciate that some people like to work this way, I don't
> think everyone does and I don't think cucumber should be enforcing
> conventions based on this.
>
> What I think *would* make sense is to offer up some
> configuration/mapping scheme that allows you to manage this in a
> number of different ways.
>
> For example, we could add something like autotest uses - if a
> .cucumber file exists it gets loaded before anything else, and it can
> be used to describe mappings as autotest does:
>
> Autotest.add_hook :initialize do |at|
> at.add_mapping %r%features/(.*).feature% do |filename, match|
>at.files_matching %r%features/#{match}.rb
> end
> end
>
> Something along those lines could help satisfy everyone's needs, no? WDYT?
>
>> My stories folder always had extra dirs, so I find the layout:
>> features/
>>descriptions/
>> apply.feature
>> open.feature
>> start.feature
>> stop.feature
>> zoom.feature
>>matchers/
>>steps/
>>support/
>>
>> MUCH easier to follow than:
>> features/
>>apply.feature
>>matchers/
>>open.feature
>>start.feature
>>steps/
>>stop.feature
>>support/
>>zoom.feature
>>
>> This is just how I use it anyway - maybe I'm alone in adding extra folders
>> like that. But I still find the nested structure much more logical than the
>> partially flat one.
>
> I see where you're coming from in terms of visibility. I tend to use
> something like this:
>
> features/
> reservations/
> schedules/
> steps/
> supplies/
> support/
>
> Admittedly, steps and support are not like reservations, schedules and
> supplies, but this has worked just fine for me so far.
>
> FWIW,
> David
>
>>
>> Ashley
>>
>> --
>> http://www.patchspace.co.uk/
>> http://aviewfromafar.net/
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] RCov / RSpec segfaults on Ubuntu
I've got a version of rcov up at github (sudo gem install spicycode-rcov --source=http://gems.github.com/) incorporating many of the fixes for rcov segfaults. So far none of the old standard crashes have crept back up. Give it a try and let me know how it works for you. -- Chad On Sat, Sep 13, 2008 at 6:36 AM, Matt Wynne <[EMAIL PROTECTED]> wrote: > Hi all, > I appreciate that this is not an RSpec question, but I wondered if anyone > out there can offer some pointers. We're using the latest versions of RSpec > and RCov, and ruby --version says this (on the Ubuntu build server): > ruby 1.8.6 (2008-07-17 patchlevel 279) [x86_64-linux] > We're getting intermittent (yes, intermittent!) segfaults from the build > when running code coverage. > It works on my (OS X 10.4) machine ;) > I can't see how to report bugs with RCov - the FAQ 'your question here'[1] > doesn't offer my anywhere to type anything. It's also suggested elsewhere on > the site that you can report issues on the release notes page[2], and I can > see plenty of other peoples' feedback, but again I can't see any way to > offer any of my own. > I must be missing something really obvious here - can anyone help me to get > in touch with whatever RCov 'community' exists? > Failing that - any good resources / tips for working around these segfault > issues - any 'no go areas' we can just avoid in our specs? I noticed, for > example, that one of our projects consistently segfaulted on this line: > /vendor/plugins/rspec/lib/spec/mocks/message_expectation.rb:41: [BUG] > Segmentation fault > Any pointers greatly appreciated. > cheers, > Matt > [1]http://eigenclass.org/hiki/rcov+FAQ#l11 > [2]http://eigenclass.org/hiki/rcov-0.8.1 > > http://blog.mattwynne.net > http://songkick.com > In case you wondered: The opinions expressed in this email are my own and do > not necessarily reflect the views of any former, current or future employers > of mine. > > > > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] ANN: RSpactor 0.9.10 (aka. beta)
Very cool, I'll try it out tomorrow. -- Chad On Mon, Apr 28, 2008 at 8:08 PM, Corey Haines <[EMAIL PROTECTED]> wrote: > I'm using rspactor now over autotest. I'll give the beta a shot. > > -Corey > > > > On Mon, Apr 28, 2008 at 3:51 PM, rubyphunk <[EMAIL PROTECTED]> wrote: > > > Hey all. > > > > I've just release a first preview/beta of the upcoming RSpactor.app; a > > spec runner for Mac OS X Leopard. This is just some kind of test > > version and I'm looking for people who love to sit on the edge :) I > > need some help to find bugs and polish the interface/interaction. > > > > RSpactor is basically a tool like 'autotest' but runs on Cocoa and > > focuses on RSpec. Instead of constantly polling your files it uses > > FSEvents to listen to changes in your project directory. Growl support > > is build in.. > > > > So if you are interested have a look at: > > > http://rubyphunk.com/2008/4/28/ann-rspactor-0-9-10-some-people-call-it-beta > > > > > > thanks. > > - Andreas > > ___ > > rspec-users mailing list > > rspec-users@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > -- > http://www.coreyhaines.com > The Internet's Premiere source of information about Corey Haines > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Welcome Pat Maddox
Congrats Pat! -- Chad On Fri, Apr 4, 2008 at 2:52 PM, Andrew WC Brown <[EMAIL PROTECTED]> wrote: > Gooble Goble, Gooble Goble, One of Us! One of Us! > > > > On Fri, Apr 4, 2008 at 2:42 PM, Brian Takita <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 4, 2008 at 10:26 AM, aslak hellesoy > > <[EMAIL PROTECTED]> wrote: > > > On 4/4/08, Luis Lavena <[EMAIL PROTECTED]> wrote: > > > > On Fri, Apr 4, 2008 at 11:35 AM, Patrick Meunier > > > > <[EMAIL PROTECTED]> wrote: > > > > > This is a great news! Congratulations Pat. > > > > > > > > > > > > > +1 on that, The bdd-force within Pat is strong, and is good to see he > > > > is joining the good side of the force :-) > > > > > > > > > > Pat is a much needed and welcome member to the core team. I expect > > > we'll see a lot of great contribs from him in the time to come. > > > > > > Welcome onboard, Pat! > > Welcome Pat. > > > > > > Aslak > > > > > > > -- > > > > > > > > > > Luis Lavena > > > > Multimedia systems > > > > - > > > > Human beings, who are almost unique in having the ability to learn > from > > > > the experience of others, are also remarkable for their apparent > > > > disinclination to do so. > > > > Douglas Adams > > > > ___ > > > > rspec-users mailing list > > > > rspec-users@rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > > > ___ > > > rspec-users mailing list > > > rspec-users@rubyforge.org > > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > ___ > > rspec-users mailing list > > rspec-users@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] OT local version control?
A good thing to note is that you can run many of the distributed scm tools in a 'svn wrapper' mode to ease transition with existing repositories. That made the switch much easier for me. - Chad On Jan 27, 2008 5:00 PM, Dan North <[EMAIL PROTECTED]> wrote: > I can see this descending into a mercurial vs git religious war :) > > Hi Corey. I'm using mercurial for both home and work use (supplementing > some of subversion's shortcomings, mainly around merging). I looked > (briefly) at git and - less briefly - at darcs. I settled on mercurial for > purely non-scientific reasons. People whose opinions I respect are using it, > the community seems both accommodating and active, and it's python which > means it runs anywhere python lives, which is all of my home and work > environments. > > Others on this list - including the lovely David - are using git and > having just as much fun and productivity, so I'm sure it comes down to a > matter of taste in the end. > > The big shift, though, is from centralised to distributed source control. > This means that any working copy is also a full repository in its own right, > so you can do everything you would usually need the server for: branching, > tagging, cloning, logging, checking in, rolling back, etc. This page ( > http://tinyurl.com/ykcs25) from the Mercurial wiki gives a pretty good > overview. The basic model will be the same for any of the distributed SCMs. > > My experience so far is: > > git: insanely fast, made up of many shell scripts, big command set, does > /BIG/ repositories (currently used for the entire linux kernel), doesn't run > on windows. > darcs: also fast, written in haskell so less "hackable". Has best > cherry-picking support (choosing out-of-sequence changesets). Apparently > doesn't do so well under biiig repositories. > mercurial: also fast (seeing a pattern here?). Seems to scale well. Has > (deliberately) svn/cvs-like command set where it can, so easy to adopt. This > is where I've ended up. > monotone: the first distributed scm I came across (Dave Astels was using > it before any of the rest of us had heard of distributed scm). Never really > used it much. > > At the end of the day it will be a personal preference. But whichever you > end up with, my prediction is that you'll enjoy it much more than > subversion. > > Cheers, > Dan > > > On 27/01/2008, Corey Haines <[EMAIL PROTECTED]> wrote: > > > Hi, all, > > > > This isn't about rspec, but this list has people whose opinions I > > respect. > > > > So, I'm looking for a new version control system for my local > > development. I was going to install subversion, but I've heard rumors of > > people using some newer ones. Thoughts? I'd like to be able to run it either > > locally or on a home server. If I run it off a home server, then it needs to > > support offline access, so that I can use a cached version when I'm not on > > my home network. For simplicity's sake, running it locally is probably a > > better solution. > > > > What do you all use? > > > > > > -Corey > > > > -- > > http://www.coreyhaines.com > > The Internet's Premiere source of information about Corey Haines > > ___ > > rspec-users mailing list > > rspec-users@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > > > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Rails: Specing libraries
Caleb, In most cases you could just create a lib folder under spec with your new file in it. For example if you have: lib/my_extension.rb You would have: spec/lib/my_extension_spec.rb That starts out something like: require File.expand_path(File.dirname(__FILE__) + '/../../spec_helper') describe MyExtension do ... end And that should about do it. -- Chad Humphries http://spicycode.com/ On Dec 22, 2007, at 1:17 PM, Caleb Land wrote: > I was reading the documentation on using rails with rspec and I > didn't see anything about how to spec libraries in the rails /lib > directory so that they're integrated into the whole spec::rails > system. > > Where should I put specs for my libraries, and what's the best way > to require the files that I'm testing in my spec? > > I've never used rspec before, and I'm new to rails, so I'm huge newb. > > -- > Caleb Land > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Installation Trouble
Also, could you post the spec if possible? - Chad On Dec 19, 2007, at 10:11 AM, David Chelimsky wrote: > On Dec 19, 2007 8:46 AM, Ben Greenberg > <[EMAIL PROTECTED]> wrote: >> >> David Chelimsky wrote: >> >> On Dec 19, 2007 7:31 AM, Ben Greenberg <[EMAIL PROTECTED] >> > >> wrote: >> >> >> Hey all, >> >> I'm new to BDD and rspec, but I am very intrigued. >> >> I tried installing rspec and rspec_on_rails into my Rails app, but >> I am >> having some trouble. >> >> I chose to install both as plugins, as the documentation suggests. I >> checked out the CURRENT tag from svn, and copied the rspec and >> rspec_on_rails directories into my app's vendor/plugins directory. >> Then I >> ran script/generate rspec, which created its files. Everything >> seemed ok, so >> I wrote up a little model spec, put it in spec/models, and ran rake >> spec. I >> did put require "File.dirname(__FILE__) + '/../spec_helper.rb'" at >> the top >> of my spec file. >> >> The message and call stack I get back is: >> >> == >> >> c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ >> active_support/dependencies.rb:266:in >> `load_missing_constant': uninitialized constant Spec::Rails >> (NameError) >> from >> c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ >> active_support/dependencies.rb:452:in >> `const_missing' >> from >> C:/src/Aptana/ir/vendor/plugins/rspec_on_rails/lib/spec/rails/ >> extensions/spec/example/configuration.rb:14 >> from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in >> `gem_original_require' >> from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in >> `require' >> from >> c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ >> active_support/dependencies.rb:495:in >> `require' >> from >> c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ >> active_support/dependencies.rb:342:in >> `new_constants_in' >> from >> c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ >> active_support/dependencies.rb:495:in >> `require' >> from >> C:/src/Aptana/ir/vendor/plugins/rspec_on_rails/lib/spec/rails/ >> extensions.rb:5 >> ... 18 levels... >> from >> C:/src/Aptana/ir/vendor/plugins/rspec/lib/spec/runner/ >> example_group_runner.rb:13:in >> `load_files' >> from >> C:/src/Aptana/ir/vendor/plugins/rspec/lib/spec/runner/options.rb: >> 83:in >> `run_examples' >> from >> C:/src/Aptana/ir/vendor/plugins/rspec/lib/spec/runner/ >> command_line.rb:19:in >> `run' >> from C:/src/Aptana/ir/vendor/plugins/rspec/bin/spec:3 >> rake aborted! >> Command ruby -I"C:/src/Aptana/ir/vendor/plugins/rspec/lib" >> "C:/src/Aptana/ir/ven >> dor/plugins/rspec/bin/spec" "spec/models/image_spec.rb" --options >> "C:/src/Aptana >> /ir/config/../spec/spec.opts" failed >> == >> >> As you can see, I am running Windows. >> >> Does anyone have any idea what I am doing wrong? >> >> Are you running this from Aptana or from the command line? >> >> >> >> Thanks for the quick reply. >> >> I am running from the command line, in my RAILS_ROOT. > > And you've got the following near the top of spec/spec_helper.rb? > > require 'spec' > require 'spec/rails' > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] 'it' duplicate example: BUG
One of the recent trunk changesets modified the default behaviour to fail fast if duplicate examples are detected within a single behaviour/ example group. This is basically letting you know you have to "it" blocks in the behaviour with the same description. Note: You may have this issue rise up if you have one in a shared behaviour and accidental duplication in the file (that was my case when I updated this morning). - Chad On Nov 21, 2007, at 1:12 PM, Scott Taylor wrote: > I svn up'ed this morning, to get the following message with rake spec: > > /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/spec/example/ > example_group_methods.rb:96:in `it': Duplicate example: 'should > contain the total number of messages' (RuntimeError) > > Anyone have any ideas why this might be going on? My specs were all > passing last night. > > Let me know if I should put this in the tracker. > > Scott > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] [rspec-devel] help anyone?
David, The move should be complete now. -Chad On Nov 18, 2007, at 5:26 PM, David Chelimsky wrote: > On Nov 18, 2007 4:16 PM, Jonathan Linowes <[EMAIL PROTECTED]> > wrote: >> David, >> >> If no one else offers a more efficient solution, I'm willing to >> manually copy the open tickets. (I count 37 of them) >> I have read access to Rubyforge >> and see this as an opportunity to get familiar with lighthouse > > Thanks Jonathan, but Chad Humpries has already offered to do this (on > the rspec-devel list). > > Also - there are 37 but there are also 9 patches and 77 feature > requests. We need them all to get moved over. > > If you want to coordinate w/ Chad and Scott (who also volunteered), > perhaps you guys can divide and conquer. > > Cheers, > David > >> >> Jonathan >> >> >> On Nov 18, 2007, at 4:16 PM, David Chelimsky wrote: >> >> >>> Hi everybody. >>> >>> Per http://rubyforge.org/pipermail/rspec-users/2007-November/ >>> 004572.html, >>> we're going to be moving ticket tracking over to lighthouse. We'd >>> like >>> to get this rolling sooner than later, but we're fairly well >>> occupied >>> getting ready for the 1.1 release and writing rspec books :) >>> >>> We've got the lighthouse account set up. The thing we need to do to >>> start using it is to get all the open tickets at rubyforge copied >>> over >>> to lighthouse. As of today, lighthouse does not offer any sort of >>> automated means of doing that. >>> >>> If any of you are interested in helping out by either manually >>> copying >>> tickets over or devising an automated means of doing so, please >>> speak >>> up. It would be a big help to the both the rspec community and the >>> rspec development team. >>> >>> Cheers, >>> David >>> ___ >>> rspec-users mailing list >>> rspec-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> ___ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > ___ > rspec-devel mailing list > [EMAIL PROTECTED] > http://rubyforge.org/mailman/listinfo/rspec-devel ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Spec/Test Speed
The Stories (ie Story Runner full integration tests that hit the db) are fairly slow by comparison, I agree. We have those run on our CI server, and only locally when we modify them. That's our approach for handling integration testing. Re: The mac mini's, yeah they were pairing stations (one per pair of users, no distributed spec running yet). Our main specs are built around heavier use of mocking/stubbing. - Chad On Oct 7, 2007, at 2:14 AM, Scott Taylor wrote: > > On Oct 7, 2007, at 1:47 AM, Pat Maddox wrote: > >> On 10/6/07, Scott Taylor <[EMAIL PROTECTED]> wrote: >>> >>> On Oct 7, 2007, at 12:31 AM, Chad Humphries wrote: >>> >>>> Scott, >>>> >>>> I don't really have a lot to contribute on how to make it faster, >>>> other than to outline what we've been doing on our projects. >>>> >>>> On one of our current projects we have the following 2570 examples >>>> that run in ~70 seconds on our pairing stations (mac minis, 1.83 >>> >>> I assume your "pairing stations" are two separate mac-minis, in >>> which >>> you practice pair programming? Or is this a cluster of two mac- >>> minis? >>> >>> But this sounds great - 70 seconds for 2500 specs. How many of >>> those >>> are model specs (that hit the database)? >>> >>>> c2d). In general across our various machines is at or a little >>>> more >>>> than a minute for specs for controllers, models, helpers, lib, >>>> views, >>>> and plugins. Our Story suite takes longer, but it's still under >>>> development so I don't really count it at this point. We have >>>> Ruby >>>> 1.8.6 installed from MacPorts on all machines, as well as MySQL 5. >>>> (current as of a month ago) from macports. >>>> >>>> We make good use of mocking and stubbing through our controller >>>> tests, and little use of fixtures. We primarily use the >>>> spec_attribute_helper (or factory method) as Luke Redpath and Dan >>>> Manges have outlined in their respective blog articles. I've >>>> been >>>> looking at deep test, or possible spec_distributed as a way to >>>> speed >>>> things up more. Our main issue is our precommit task (rake cruise >>> >>> The factory method (or attribute_helper) still hits the database. I >>> don't see it as any sort of performance gain. In fact, I've even >>> developed a plugin around the Factory idea, and it was only when I >>> started using it in all of my tests that the speed really started to >>> affect me (I was using mocking/stubbing, with much frustration prior >>> to that point). But to me it's pretty clear the plugin (or the >>> factory) is not the problem - the hit is the database. DHH saw this >>> hit, and since they were using fixtures,he found that creating the >>> fixtures, and then wrapping each test in a transaction was a huge >>> performance gain. I wonder if the same would be true with setups/ >>> before(:each)... >>> >>> The obvious thing to do to solve the performance problem is to >>> remove >>> the hit to the database. The question is: At what level of >>> abstraction should this be done? The one camp (which would include >>> fellows like Jay Fields), would mock/stub everything they don't >>> write. For me, I see testing as more than testing - it's the >>> documentation to my code which never lies to me (this documentation >>> is so good, that I can give it to my boss, who is not a programmer). >> >> I think you'd be far better served by user stories in this case. The >> user story is the tool we use to communicate with non-geeks, be it >> customers or our boss. Low-level specs fall squarely in the >> developer >> realm, as far as I'm concerned. They're easy to read because we >> don't >> like to torture ourselves. I think that they're fantastic for >> communicating intent with other developers, but that's where it ends. >> >> So, when you move documentation as a goal from specs over to stories, >> that frees specs to take advantage of techniques like mocks to help >> with your design. Documentation is a pleasant side effect of BDD, >> not >> a goal. > > Documentation is certainly a goal of BDD (Just not necessarily for > the business user - as you pointed out). I don't
Re: [rspec-users] Spec/Test Speed
Scott, I don't really have a lot to contribute on how to make it faster, other than to outline what we've been doing on our projects. On one of our current projects we have the following 2570 examples that run in ~70 seconds on our pairing stations (mac minis, 1.83 c2d). In general across our various machines is at or a little more than a minute for specs for controllers, models, helpers, lib, views, and plugins. Our Story suite takes longer, but it's still under development so I don't really count it at this point. We have Ruby 1.8.6 installed from MacPorts on all machines, as well as MySQL 5. (current as of a month ago) from macports. We make good use of mocking and stubbing through our controller tests, and little use of fixtures. We primarily use the spec_attribute_helper (or factory method) as Luke Redpath and Dan Manges have outlined in their respective blog articles. I've been looking at deep test, or possible spec_distributed as a way to speed things up more. Our main issue is our precommit task (rake cruise which our ci server also runs) executes rcov to test for full coverage and adds 15-25 seconds to the whole thing bringing it up to a minute and a half. We also make heavy use of some simple custom rcov tasks ala rake app:coverage:models, rake app:coverage:lib, etc to help when we are working on slices of the apps. So far we have found that regardless of the wait (and the increased chances of wandering about to other tasks) we always want to run the full stack locally and not just a slice. Then again all this strikes me as rather funny as I remember waiting 5 or 6 minutes back in my .NET days for a quarter our tests to run, with no coverage report. I guess ruby and rspec spoiled me :) - Chad NOTE: Our project is on EdgeRails (few revisions back) and Trunk RSpec On Oct 6, 2007, at 11:16 PM, Scott Taylor wrote: > > On Oct 4, 2007, at 6:11 AM, Jerry West wrote: > >> In-memory with sqlite worked fine with rspec-0.8 (it's been a while >> since I did this!). Google for instructions or drop me a line. >> Don't >> forget autotest/zentest to run only those tests which have ben >> affected >> by changes. > > > Actually, on my current rails project I can't use sqlite, because of > a bug in rails: > > http://dev.rubyonrails.org/ticket/9385 > > So out goes that idea (at least for the forseeable future). What > speed difference do you see with in-memory database? > > I'm already using ZenTest. When going from red -> (subset) green => > (all) green, the last step is killing me (because I have to wait > around for 2 minutes for all the specs to fail. This usually results > in me spending a lot of time responding to emails while I should be > developing ;) > > Scott > > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Failure Messages in RSpec
I generally write custom expectation matchers when I want more specific information on failure scenarios. Granted this might not work in all scenarios (taking time to write a custom matcher I mean), but for most things it has made it very nice. -Chad On Sep 4, 2007, at 5:08 PM, Jay Levitt wrote: > Shane Mingins wrote: >> >> On 5/09/2007, at 8:51 AM, Geoffrey Wiseman wrote: >> >>> >>> Using this as an example, if a new validation rule is added, this >>> test >>> will fail without indicating /why/. Sure, I can get that answer in >>> other ways, but I'd hate to discover things like: >>> >>> it "should be valid with valid attributes" do >>> # puts @person.errors if [EMAIL PROTECTED] >>> @person.should be_valid >>> end >>> >> >> Sorry if I missed the point of this, but in the context of having an >> optional failure message >> >> I am curious as to how an optional message param to the assertion >> would >> help you in this case? > > Seems like, in this case, he'd output @person.errors in his message so > he could see *why* person was invalid; the "puts" is his current > hack-around for the lack of custom messages. > > Not a bad idea, really. (the custom messages, not the hackaround!) > > Jay > > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
Re: [rspec-users] Deprecating the mocking framework?
Zach, I believe version 0.7.0 has the global ordering you are looking for: Version 0.7.0 Added and_yield as an expectation clause. Inspect on Mocks now yield a more consise description. Global ordering across all mocks in a container is now allowed. Added support for Demeter chain mocking. Deprecated a number of mock_* methods. -Chad On Sep 3, 2007, at 12:08 AM, Zach Dennis wrote: > On 9/2/07, Andrew WC Brown <[EMAIL PROTECTED]> wrote: >> I think that makes sense. >> >> Which do you recommend? Flexmock or Mocha? >> > > I wouldn't recommend either of them by themselves, at least the > current way they sit. > > Jim Weirich may be adding globally ordered strict mocks, which if he > does then I think Flexmock will be the first mocking library in ruby > to cover all mocking needs (as far as I know). > > Mocha (and RSpec mocks too) don't support globally strict ordered > mocks. Hardmock is another mocking library which is just strict > mocking (no stubs, no partial mocks). Right now I prefer Mocha + > Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally > strict ordered mocks. > > Zach Dennis > http://www.continuousthinking.com > ___ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users ___ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
