Full Of Caffeine

Steak is a great lightweight replacement for Cucumber. I’m not going to dig into it here since it’s not the point of this post, but suffice to say it is basically rSpec for acceptance/integration tests (aka features in the Cucumber world, whatever you prefer).

I’ve been having some issues with Steak though. The default Steak generator creates the infra-structure under spec/. At first sight, it doesn ‘t seem that bad, after all, acceptance tests are just specs with added sugar, right? Well, not really.

Even though Steak acceptance tests are just rSpec at its core, the nature of it make them a different beast. First, you often need to use Culerity with them. This also brings the need to use DatabaseCleaner. If you keep all of this under spec/, the rake spec task will load and run it all, including the DatabaseCleaner configuration, wreaking havoc with your rSpec unit-tests. Also, you often don’t want to run acceptance tests when running the suite of unit-tests, acceptance/integration tests are often much slower.

I’ve already opened an issue here on Steak’s github issues page. However, if you want to fix it now, here’s what you need to do.

1) First, move the acceptance directory out of spec/. I recommend moving it to the application’s top-level directory (RAILS_ROOT);
2) Now, open acceptance/acceptance_helper.rb and correct the require for spec_helper. If you’ve put the acceptance directory on RAILS_ROOT, the require should look like this:

"require File.dirname(__FILE__) + "/../spec/spec_helper"

3) Open lib/tasks/steak.rake, and correct all the references to the acceptance directory, again, if you’ve put on RAILS_ROOT, you just remove the “spec/” part on the path string. It would look like:

nless ARGV.any? {|a| a =~ /^gems/} # Don't load anything when running the gems:* tasks

  require 'spec/rake/spectask'

  ENV['RAILS_ENV'] = 'development'
namespace :spec do
  desc "Run the code examples in spec/acceptance"
  Spec::Rake::SpecTask.new(:acceptance => "db:test:prepare") do |t|
    t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]
    t.spec_files = FileList["acceptance/**/*_spec.rb"]
  end

  # Setup stats to include acceptance specs
  task :statsetup do
    require 'code_statistics'
    ::STATS_DIRECTORIES << %w(Acceptance\ specs spec/acceptance) if File.exist?('acceptance')
    ::CodeStatistics::TEST_TYPES << "Acceptance specs" if File.exist?('acceptance')
  end
end

end

Now you can run "rake spec:acceptance" for Steak acceptance tests, and "rake spec" for the rest of unit-tests.

Don’t ever install rake and or rubygems from debs (or any other distro package manager). For rubygems, get from rubygems.org, for rake, install it through gem. If you are using Ubuntu, for example, don’t use apt-get to install rake, nor rubygems, you’ll waste your time wondering aftewards why rake can’t find gems, for example.

It’s never an easy task to refactor infra-strcuture, specially if it uses different libraries. That’s the case with my latest endeavour of migrating from the Cucumber+WebRat+Selenium combo to Steak+Capybara+Culerity combo. The reason? Simplify. The process? Boring and troublesome, but *** happens and we have to deal with it

Anyway, if you are getting the following error when trying to run your acceptnace test spec/Cucumber feature when using Capybara+Culerity/Celerity:

custom_require.rb:31:in `require': no such file to load -- celerity (LoadError)

This is because (well, at least was for me) you haven’t installed the celerity gem on your local ruby (note the empahasis — not jruby!) installation. Do so:

 $ sudo gem install celerity

Now, I will blame this confusion on the Culerity docs. The documentation states:

You will need the celerity gem installed into JRuby:

jruby -S gem install celerity

Now install the Culerity gem:

gem install culerity –source http://gemcutter.org

So, it instructs you to install celerity on jruby but not on ruby. But this didn’t work for me at all.

Anyway, feel free to comment/contact me if you could make it work the way it’s told on the documenation. Hope this saves someone else’s time

So, today I decided to replace Cucumber with Steak + Capybara and Culerity. Albeit I believe this has been a good choice (I’ve found Cucumber too heavy for our needs, and since the stakeholders are also developers, we don’t really need, nor used Cucumber, so it wasn’t aggregating any value at all), I’ve had a small issue with Culerity, more specifically with its culerity:rails:start rake task.

If you check the documentation, you’ll see that before running your feature/acceptance specs that use Culerity (and hence, Celerity) you will need to start a Rails server, which will be used by the Celerity HTMLUnit client. Ok, so far, no problems, Cucumber and Webrat used to do that automatically for us, but it’s not a big deal. So I went to the terminal and typed:

$ rake culerity:rails:start

Boom! Got the following output:

rake culerity:rails:start/Library/Ruby/Gems/1.8/gems/rails-2.3.5/lib/commands/server.rb:104:in `write': Broken pipe (Errno::EPIPE)
from /Library/Ruby/Gems/1.8/gems/rails-2.3.5/lib/commands/server.rb:104:in `puts'
from /Library/Ruby/Gems/1.8/gems/rails-2.3.5/lib/commands/server.rb:104
from script/server:3:in `require'
from script/server:3

I’ve opened the server.rb, and the line 104 for Rails 2.3.5, has the following code:

puts "=> Call with -d to detach"

Hmm… after a moment, I also realized this wasn’t a “fatal error”. The server was actually being started succesfully, behind the scenes. The issue was that the output was not being redirected to stdout, thus, a Errno::EPIPE (I’m not sure which component throws this exception though, if someone knows, please shed some light).

So, if you can live with it, just wait a few seconds and everything should work out fine.

However, it would be good to:
* See the output of your test Rails server;
* Use the debugger on this Rails server;
* Have the damn pid file removed when you send a SIGINT (Ctrl+C) to the rake task.

Well, fear not. Just replace the code for the task :start on RAILS_ROOT/lib/tasks/culerity.rake with the following code and go get some fresh coffee:

task :start do
port = ENV['PORT'] || 3001
environment = 'test'
pid_file = RAILS_ROOT + "/tmp/culerity_rails_server.pid"
if File.exists?(pid_file)
puts "culerity rails server already running; if not, delete tmp/culerity_rails_server.pid and try again"
exit 1
end
rails_server = IO.popen("script/server -e #{environment} -p #{port}", 'r+')
File.open(pid_file, "w") { |file| file << rails_server.pid }

running = true

Signal.trap('SIGINT') {
puts 'terminating'
running = false
rm = `rm -rf #{RAILS_ROOT}/tmp/culerity_rails_server.pid`
}

while running
$stdout << rails_server.gets
end

end

This works for culerity 0.2.10, as of 8/June 2010.

Another possibility would be to add a & here, like this:

culerity.rake:12

rails_server = IO.popen("script/server -e #{environment} -p #{port} &", 'r+')

I think this was the intended way to use the tasks, since there is also a rake task to stop the process (by using the pid in the pidfile), so probably the missing ampersand could be considered a bug.

I was about to run Bundler, and I wanted to test if the command would accept the name of a gem to install as an argument, like this:


bundle install capybara-envjs


This ran the whole bundle, and didn’t install only capybara-envjs, but not a big deal — I just ignored that fact and kept working. Eventually, I noticed the capybara-envjs misteriously sitting at the root of the Rails application. What was that? Happens it contained all the gems from my Gemfile!

Happens that the argument you pass after install tells bundler where you want to install the gems to. Not so obvious.

Anyway, if you happen to fall in the same “trap”, just edit .bundle/config in the root of you Rails app and set the value of BUNDLE_PATH to the correct path (usually ~/.bundle).

So, you want to dig into your huge logfile, you know that the information you are searching contains a piece of data, but you also want the context around it. Definetly not good to load the entire log file into memory, if it’s too big. Also, not very convenient to search manually using an editor. What do you do?

Use grep:


$ grep /path/to/file -An -Bn


Where n is an integer. -A specifies the number of lines to be printed after the match, and B does for the lines before, as you might have guessed.

Pretty useful.