I'm using guard-rails to run my rails server, my problem is I can't access the REPL when I add binding.pry I just get
From: /home/martinr/code/app/controllers/tools_controller.rb # line 2 ToolsController#index:
2: def index
=> 3: binding.pry
4: #end_date = Date.today.to_s
5: #start_date = Date.today.months_ago(3).to_s
7: end
[1] pry(#<ToolsController>)>
No REPL, how do I use pry with guard rails?
My Gemfile file looks like this
group :development, :test do
gem 'pry-rails' # for better console debugging
gem 'pry-debugger'
gem 'rb-inotify'
gem 'sqlite3'
end
My Guardfile:
guard 'rails', :debugger => true do
watch('Gemfile.lock')
watch(%r{^(config|lib)/.*})
end
I've set up my rails environment with Guard and Spork and I find that binding-pry acts strangely with guard. If I insert binding.pry into the code and then guard restarts my tests, there's no interactive debugging. But if I exit and start guard up again, it's working and breaks into interactive mode correctly.
However... if I then remove the binding.pry line, guard will rerun the tests as it is supposed to, but will break at where the binding line used to be, even though it isn't there anymore.
Seems you have to restart guard every time you insert or remove the pry binding.
Irritating but still better than not having access to pry in your tests.
I'm trying a similar thing, and also can't get it to work. The issue seems that reading from stdin does not block, so Pry does not block. Any read from STDIN returns right away.
rspec -X console.rb
File follows:
require 'spec_helper'
describe 'console' do
it 'opens!' do
Pry.config.input = STDIN
Pry.config.output = STDOUT
puts STDIN.closed? # returns false
binding.pry # returns right away, does not block
gets # returns right way, does not block
end
end
Related
I'm trying to set up the sinatra-authentication gem in a simple sinatra app, and running into an issue where sinatra can't find the correct views. I understand that sinatra-authentication uses haml by default, but I'm using erb in this app.
This in mind, I found in the sinatra-authenticaiton docs that there is a setting which allows you to change the template engine, by adding the following to your app file:
configure do
set :template_engine, :erb # for example
end
I've added this to my app.rb file, and sinatra is still looking for the signup.haml when I try to hit the /signup route in my app.
A couple of notes:
I've included the gem in my Gemfile, and successfuly run a bundle install on my app.
source 'https://rubygems.org'
gem 'sinatra'
gem 'data_mapper'
gem 'pg'
gem 'dm-postgres-adapter'
gem 'sinatra-authentication'
I saw something in the documentation that suggested that I may need to specify the location of my view files, so I added the following to my configuration block.
set :sinatra_authentication_view_path, Pathname(__FILE__).dirname.expand_path + "views/"
**I think I've required the gem accurately in my app file by adding
require "sinatra-authentication"
use Rack::Session::Cookie, :secret => 'mys3cr3tk3y'
This gist is a current representation of my app.rb file in the root of my sinatra app. https://gist.github.com/rriggin/5378641#file-gistfile1-txt
Here is a screenshot of the error sinatra throws: http://cl.ly/image/0y041t0K3u3O
When I run the app locally, a 'dm-users' table is created in my local db as expected.
Is there another configuration setting that I'm missing in order to get sinatra-authentication to properly look for the erb templates rather than haml files. Any help would be greatly appreciated.
Thanks
The specs don't test that the template_engine setting works, and looking at the way the setting is called, I believe it's not correct, i.e.
send settings.template_engine, get_view_as_string("index.#{settings.template_engine}"), :layout => use_layout?
might better work as:
send app.settings.template_engine, get_view_as_string("index.#{app.settings.template_engine}"), :layout => use_layout?
that's what I reckon. If you fork the project, change the line and add it to your Gemfile and it works then consider writing a quick spec for it and you'll have improved the mainline of that project as well as fixed your problem.
I want to build a rails3 website authed with LDAP, so I chose ruby-ldap gem (not net/ldap) which we used in our old rails2 apps and works very well.
But I keep on getting weird error in rails3 app, See the codes below:
require 'ldap'
class WelcomeController < ApplicationController
def index
begin
#test = LDAP::Conn.new('10.72.64.11', 389)
rescue LDAP::Error
p LDAP::Error
end
render :text => "ok"
end
end
welcome#index is my root route. Most time, the app crashes when going to LDAP::Conn.new('10.72.64.11', 389), even I tried to use "pry" to debug and track, throwing
[1] 24797 trace trap rails s
and the WEBrick server will be terminated right that time.
Sometimes it throws another type error when I use "pry" to step,
#<NameError: uninitialized constant WelcomeController::LDAP>
While try it in the console, everything goes well.
1.9.3-p194 :001 > require 'ldap'
=> true
1.9.3-p194 :002 > #test = LDAP::Conn.new('10.72.64.11', 389)
=> #<LDAP::Conn:0x00000101289568>
1.9.3-p194 :003 >
Can you guide me out of this crazy stuff? I am using ruby 1.9.3p194 and rails 3.2.8
A few months later, I kind of figure out what the problem is...
The ruby-ldap gem has problem on running on the rails default server: Webrick.
Try Pow or Passenger, it works perfect!
After reading this page: http://www.ruby-forum.com/topic/62920
I tried moving the require 'ldap' from the controller or model file, and into the very top line of my environment file (xxxlocal.rb)
After I did that, I was able to run it ok in webrick also.
I am using the following piece of code on my ApplicationController :
rescue_from ActiveRecord::RecordNotFound, :with => :not_found
def not_found
render :nothing => true, :status => :not_found
end
in order make Rails respond with correct status code and not raise an exception
in development mode.
I know that how-to-handle-errors-like-404-500-in-rails3 explains how Rails works in production mode. In other words, what I am trying to do in development mode is done without any piece of code in production mode.
How can I make development mode behave like production mode and get rid of the above piece of code?
Note that I am using Rails 3.2.3
Perhaps you want to turn this off?:
config.consider_all_requests_local = false
This is set to true in config/environments/development.rb by default.
ruby-1.9.2-p180 :007 > Factory.define :user do |user|
ruby-1.9.2-p180 :008 > user.email "user#example.com"
ruby-1.9.2-p180 :009?> user.password "foobar"
ruby-1.9.2-p180 :010?> user.password_confirmation "foobar"
ruby-1.9.2-p180 :011?> end
NameError: uninitialized constant Factory
My Gemfile:
group :test do
gem "rspec-rails"
gem 'webrat', '0.7.1'
gem 'spork', '0.9.0.rc4'
gem 'factory_girl_rails'
end
Even tough it seems I have everything as it should, I keep getting that error. I also have factories.rb created.
Thanks
I suppose you try in console in development environment. But you add the Factory gem only in test environment.
If you want access to Factory_girl in development use in your Gemfile :
group :test, :development do
gem 'factory_girl_rails'
end
Or if you want test your Factory launch your console in test environment :
rails c test
We had a similar problem on our end, rake spec seemed to be randomly failing with the error uninitialized constant FactoryGirl. The error was random -> coming and going. We went back half a dozen git commits to try and resolve it. In the end it was a silly mistake.
The fundamental problem is RAILS_ENV is set to development. It needs to be set to test when you run rake spec.
Address by:
Making certain that we are running rake spec in the RAILS_ENV test environment and its exported/sourced properly. To never confuse our environemnts, we modified zsh $RPROMPT env variable to show the current env.
export RPROMPT="[%{$fg_no_bold[yellow]%}$RAILS_ENV%{$reset_color%}]"
Require FactoryGirl in the spec ruby files gave a much better error message. At least rspec would run vs just fail outright this way when the environment was wrong. We also updated our gemfile to make sure factory_girl_rails and factory_girl were loaded both for development and testing.
Now we just run rpsec using the gem guard in a dedicated terminal with the proper RAILS_ENV set.
Its one of those gotchas.
We're running Ruby 1.9.3, Rails 3.2.9, Rspec 2.12, factory_girl 4.1.
I also ran into this while I was doing the Hartl tutorial.
If you are using "Spork" to speed up your tests and it is running in the background when you add the FactoryGirl code, you will need to stop it and restart it.
You should also change Factory.define to FactoryGirl.define, like in this example
FactoryGirl.define do
factory :user do
name 'John Doe'
date_of_birth { 21.years.ago }
end
end
from the factory_girl documentation
It is pretty easy with the added generator of rspec-rails to set up RSpec for testing a Rails application. But how about adding RSpec for testing a gem in development?
I am not using jeweler or such tools. I just used Bundler (bundle gem my_gem) to setup the structure for the new gem and edit the *.gemspec manually.
I also added s.add_development_dependency "rspec", ">= 2.0.0" to gemspec and did a bundle install.
Is there some nice tutorial what to do next to get RSpec working?
I've updated this answer to match current best practices:
Bundler supports gem development perfectly. If you are creating a gem, the only thing you need to have in your Gemfile is the following:
source "https://rubygems.org"
gemspec
This tells Bundler to look inside your gemspec file for the dependencies when you run bundle install.
Next up, make sure that RSpec is a development dependency of your gem. Edit the gemspec so it reads:
spec.add_development_dependency "rspec"
Next, create spec/spec_helper.rb and add something like:
require 'bundler/setup'
Bundler.setup
require 'your_gem_name' # and any other gems you need
RSpec.configure do |config|
# some (optional) config here
end
The first two lines tell Bundler to load only the gems inside your gemspec. When you install your own gem on your own machine, this will force your specs to use your current code, not the version you have installed separately.
Create a spec, for example spec/foobar_spec.rb:
require 'spec_helper'
describe Foobar do
pending "write it"
end
Optional: add a .rspec file for default options and put it in your gem's root path:
--color
--format documentation
Finally: run the specs:
$ rspec spec/foobar_spec.rb
Iain's solution above works great!
If you also want a Rakefile, this is all you need:
require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new(:spec)
# If you want to make this the default task
task default: :spec
Check the RDoc for RakeTask for various options that you can optionally pass into the task definition.
You can generate your new gem with rspec by running bundler gem --test=rspec my_gem. No additional Setup!
I always forget this. It's implemented here: https://github.com/bundler/bundler/blob/33d2f67d56fe8bf00b0189c26125d27527ef1516/lib/bundler/cli/gem.rb#L36
Here's a cheap and easy (though not officially recommended) way:
Make a dir in your gem's root called spec, put your specs in there. You probably already have rspec installed, but if you don't, just do a gem install rspec and forget Gemfiles and bundler.
Next, you'll make a spec, and you need to tell it where your app is, where your files are, and include the file you want to test (along with any dependencies it has):
# spec/awesome_gem/awesome.rb
APP_ROOT = File.expand_path(File.join(File.dirname(__FILE__), '..', '..'))
$: << File.join(APP_ROOT, 'lib/awesome_gem') # so rspec knows where your file could be
require 'some_file_in_the_above_dir' # this loads the class you want to test
describe AwesomeGem::Awesome do
before do
#dog = AwesomeGem::Awesome.new(name: 'woofer!')
end
it 'should have a name' do
#dog.name.should eq 'woofer!'
end
context '#lick_things' do
it 'should return the dog\'s name in a string' do
#dog.lick_things.should include 'woofer!:'
end
end
end
Open up Terminal and run rspec:
~/awesome_gem $ rspec
..
Finished in 0.56 seconds
2 examples, 0 failures
If you want some .rspec options love, go make a .rspec file and put it in your gem's root path. Mine looks like this:
# .rspec
--format documentation --color --debug --fail-fast
Easy, fast, neat!
I like this because you don't have to add any dependencies to your project at all, and the whole thing remains very fast. bundle exec slows things down a little, which is what you'd have to do to make sure you're using the same version of rspec all the time. That 0.56 seconds it took to run two tests was 99% taken up by the time it took my computer to load up rspec. Running hundreds of specs should be extremely fast. The only issue you could run into that I'm aware of is if you change versions of rspec and the new version isn't backwards compatible with some function you used in your test, you might have to re-write some tests.
This is nice if you are doing one-off specs or have some good reason to NOT include rspec in your gemspec, however it's not very good for enabling sharing or enforcing compatibility.