rspec

Comments and changes to this ticket

• 

  Rob Sanheim April 27th, 2008 @ 07:13 AM

  I can submit a patch, bit I wanted to see what method you guys would prefer to make it play nicer with other spec frameworks...

• 

  David Chelimsky April 28th, 2008 @ 07:49 AM

  • → Assigned user changed from “” to “David Chelimsky”

  Hey Rob - I'm open to anything that helps rspec play nice with other frameworks as long as it also plays nice with rspec :)

  Unfortunately, while adding && ENV['RSPEC'] to discover.rb does work to prevent rspec from being discovered when you don't want it to be, it actually prevents it from EVER being discovered.

  The reason is that no files from inside your project directory (including .autotest) are loaded until after the specific autotest class is loaded. So even if you have ENV['RSPEC'] defined in .autotest, it won't cause rspec to be discovered because the discovery process is over by the time .autotest is loaded.

  Also consider that autotest considers any app with a config/environment.rb file to be a rails app. So much for autotest playing nice any other framework that likes that same structure.

  So perhaps this needs to be addressed in ZenTest. WDYT?

• 

  Rob Sanheim April 29th, 2008 @ 02:06 PM

  David:

  The ENV["RSPEC"] check actually looks at your current environment, so you could force autotest to use rspec mode like this (I just tried this out, so it really works =) ):

  :~/src/relevance/oss/github/cap_gun$ RSPEC=true autotest
  loading autotest/rspec
  /opt/local/bin/ruby -S /opt/local/lib/ruby/gems/1.8/gems/rspec-1.1.3/bin/spec  spec/cap_gun_spec.rb
  

• 

  Rob Sanheim April 29th, 2008 @ 02:06 PM

  And then you could add your own 'autorspec' command that would do that for you, so it wouldn't burden end users with having to remember the env var before autotest...

• 

  Scott Taylor May 1st, 2008 @ 09:46 AM

  Why does the .autotest file (in your own project) fail? Is rspec's .autotest loaded before (or after)?

  Either way:

  Autotest should be smart enough to run both Test::Unit and Rspec, not just one of them. Not sure exactly how this would work with two sets of mappings.

  Another option is to have autotest take command flags, like --test --spec to override the default behaviour.

  I don't really see this as a problem with rspec's implementation: it's a problem with autotest, which was never imagined to work with a spec directory.

• 

  Josh Knowles May 7th, 2008 @ 04:46 AM

  For what its worth I ran into this exact scenario, where the project I took over was using test/unit & test/spec and I added rspec. End of the day I got frustrated trying to hack autotest to understand both the tests and the specs and I just made it such that autotest would only run specs, which of course is a FAIL for those on the team still maintaining the tests.

  I would have no problem running both an autotest and an autospec. Ideally something that recognized changes to my stories as well would be nice.

• 

  Rob Sanheim May 8th, 2008 @ 06:52 AM

  Scott -- its a problem with rspec being overly aggressive in assuming that the existence of a spec directory means I want to use rspec's autotest handling, as opposed to my own autotest mapping.

  This really isn't a big deal, I just figured rspec could be made friendlier with other spec frameworks without much trouble. If not, I can just continue to hack the rspec gem or just uninstall the gem and vendor it when necessary.

  thanks,

  Rob

• 

  David Chelimsky May 8th, 2008 @ 02:41 PM

  re: running both test and spec directories: you can do this with mappings in .autotest

  re: running stories: you can do this with mappings in .autotest

  re: an autospec command - I think this is a reasonable compromise barring a solution in autotest, but I think we should be looking there first. The whole reason for autotest/discovery was to decrease coupling between tools like rspec and autotest. A new command that would have to monkey patch or duplicate code in autotest would increase that coupling, so it strikes me as a step backwards.

  Not saying Ryan should solve this. We should. But I think we should look to solve it in autotest first.

• 

  Mason Lee June 9th, 2008 @ 07:27 AM

  Hello. I've run into something like this after adding rspec to a rails app which previously had autotest set up to run test unit. All of the sudden autotest decides it run only the rspec stuff.

  David, you said: "re: running both test and spec directories: you can do this with mappings in .autotest". Can you explain more?

  Thanks,

  Mason

• 

  David Chelimsky June 9th, 2008 @ 01:58 PM

  Mason - take a look at lib/autotest/rails_rspec.rb in the rspec-rails plugin. You'll see a series of calls to add_mapping. If you do something similar in your own .autotest file (in the root directory of your rails project) you can modify the mappings as you wish.

  So, for example, in .autotest, start out by clearing the mappings:

  Autotest.add_hook :initialize do |at|
    at.clear_mappings
  end
  

  Then, to get changes to models to run the appropriate model specs and tests:

  Autotest.add_hook :initialize do |at|
    # ...
    at.add_mapping(%r%^app/models/(.*)\.rb$%) { |_, m|
      ["spec/models/#{m[1]}_spec.rb","test/units/#{m[1]}_test.rb"]
    }
    # ...
  end
  

  That's based on rails conventions. If you use any other conventions for where your model tests go, just use those instead.

  Make sense?

• 

  David Chelimsky June 19th, 2008 @ 05:33 AM

  • → State changed from “new” to “resolved”
  • → Milestone changed from “No-Milestone-Assigned” to “1.1.5”

  (from [c12b4e0cdcae1309725eeee75ce85110b905f432]) Add autospec binary to allow other spec frameworks to use autotest. [#394 state:resolved milestone:"1.1.5"]

  http://github.com/dchelimsky/rsp...