I'm clearly doing something wrong. I'm trying to write and test plain ruby in a single file. I want guard to watch the file and the test file and run minitest any time either file changes.
So, two files: game.rb and game_test.rb
game.rb
class Game
end
game_test.rb
require 'rubygems'
require 'minitest/autorun'
require './game'
class GameTest < MiniTest::Unit::TestCase
def test_truth
assert true
end
end
I also have a Guardfile that looks like this:
notification :terminal_notifier
guard 'minitest', test_folders: '.' do
watch('game.rb')
watch('game_test.rb')
end
Now, I'm probably forgetting something, but I can't for the life of me figure out what it is.
If I start guard and press Enter, "Run All" happens and the tests run.. at least most of the time. However, I have to press Enter for it to happen.
Also, if I make a change to the files nothing happens. I've tried putting gem 'rb-fsevent' in a Gemfile and running with "bundle exec guard" but that doesn't seem to help either.
Any help would be much appreciated. I'm going nuts.
Thanks,
Jeremy
Your first "watch" definition will simply pass "game.rb", which is not a test file so it won't be run.
The second "watch" is correct so when you save "game_test.rb", the tests should run.
This should be a more correct Guardfile:
notification :terminal_notifier
guard 'minitest', test_folders: '.' do
watch('game.rb') { 'game_test.rb' }
watch('game_test.rb')
end
Related
If I have file.rb:
puts "Hello, World"
then in irb type:
require "./file.rb"
the output will be Hello, World.
Why then, if I have a sinatra file, e.g.
require "sinatra"
get "/" do
return "Hi"
end
and require that, there is no output?
Clarification
What executing the sinatra file via ruby sinatra_app.rb it will start a rack server, and not stop until CTRL+C is pressed. Why does it not do that when required in irb, but it does do that when it is explicitly run with ruby sinatra_app.rb?
Because the script doesn't output anything. There is nothing in the script you showed that would generate any sort of output, there are no calls to print, puts, or p, no writes to any file, nothing.
The first script prints something when required, because it prints something, the second prints nothing when required because, well, it prints nothing. Remove the call to puts from the first script and it won't print anything either. Add a call to puts to the second script and it will print something.
Workaround is require sinatra before requiring file.
Root file:
require "sinatra"
require "/tmp/ddd.rb"
Required file:
get "/" do
return "Hi"
end
I guess it's somehow related to Sinatra startup process. They put get method in default namespace, without namespacing it to separate module.
I was given a sample sinatra project with a hello world for capybara testing in akephalos. I understand the concept by looking at the code, but how do i run it? If I run rackup config.ru, and then go to :9292 I just see a hello world. Great, what is that telling me? How do I run the test? The project is bare bones, but below is a file called example_spec.rb. How can I see it fail, for example by looking for "Hi world" and watching it fail? Hope this is enough info. Thought I would check here before I ask the dude that supplied me with the test, thanks!
# describe and context blocks are optional but help organize things
describe 'the index page' do
include x
# :js => true is used to run the test in Firefox. Otherwise it runs headless
# and without JS support
it 'can view the index page', :js => true do
visit '/'
# check to see if the page has the following text (ignoring tags)
page.should have_content('Hello, world!')
# visit https://github.com/jnicklas/capybara to see a complete list of
# assertions
end
You need to set Capybara.app = <your Sinatra class>. Perhaps something like this:
setup do
Capybara.app = Main
end
bundle exec rspec spec, This means run "bundle exec rspec" on the "spec" directory
I'd like to test class and gem loading. Have a look at the following stupid test case:
require 'rubygems'
require 'shoulda'
class SimpleTest < Test::Unit::TestCase
context 'This test' do
should 'first load something' do
require 'bundler'
assert Object.const_defined? :Bundler
end
should 'second have it reset again' do
assert !Object.const_defined?(:Bundler)
end
teardown do
# This works, but is tedious and unclean
#Object.send :remove_const, :Bundler rescue nil
# Instead I want something like this ;)
magic_reset
end
end
end
How about creating a subclass of Test::Unit::TestCase which runs the test method in a forked process?
class ForkingTestCase < Test::Unit::TestCase
def run(...)
fork do
super.run(...)
# somehow communicate the result back to the parent process
# this is the hard part
end
end
end
If this can be implemented, it should then just be a matter of changing the base class of your test case.
AFAIK, you cannot unload a file that you have loaded. You need to start a separate Ruby process for every test. (Or a separate Ruby instance if you are running on a Ruby implementation which supports multiple instances in the same process.)
Try using Kernel#load with wrap set to true:
load(filename, wrap=false) → true
Loads and executes the Ruby program in the file filename. If the
filename does not resolve to an absolute path, the file is searched
for in the library directories listed in $:. If the optional wrap
parameter is true, the loaded script will be executed under an
anonymous module, protecting the calling program’s global namespace.
In no circumstance will any local variables in the loaded file be
propagated to the loading environment.
each time you want to do a test of bundler, load it into a new anonymous module, do your tests on the bundler class within that module, and then go onto your next test.
If your code refers to the Bundler constant, then you'd have to set and unset that constant, though.
I haven't tried it myself, but can't see why it wouldn't work.
Try keeping track of what constants were defined before your tests started, and what constants are defined after your test finished, and remove the constants that were defined during the test.
I guess this isn't so much telling you how to call magic_reset as how to implement magic_reset.
edit: this problem only happens sometimes
This only appears to happen when I run the test from within TextMate (even when I specify the ruby to run it from by hand with a shebang). If I run it from the terminal then everything is peachy…
Here's some code:
require 'test/unit'
require 'shoulda'
class TestingTest < Test::Unit::TestCase
context "My thing" do
should "always have this test fail, and give me this message" do
assert false
end
end
end
I'm expecting it to tell me something like:
1) Failure:
test: My thing should always have this test fail, and give me this message (TestingTest)
# etc
An assert message, if one was given
But I'm getting:
1) Failure:
test:8
Failed assertion, no message given.
So what am I missing? The example code above is as simple as I think I can make it and I can't see the problem!
try inheriting from ActiveSupport::TestCase instead of the Test::Unit::TestCase
Can I drop to an IRB prompt from a running Ruby script?
I want to run a script, but then have it give me an IRB prompt at a point in the program with the current state of the program, but not just by running rdebug and having a breakpoint.
Pry (an IRB alternative) also lets you do this, in fact it was designed from the ground up for exactly this use case :)
It's as easy as putting binding.pry at the point you want to start the session:
require 'pry'
x = 10
binding.pry
And inside the session:
pry(main)> puts x
=> 10
Check out the website: http://pry.github.com
Pry let's you:
drop into a session at any point in your code
view method source code
view method documentation (not using RI so you dont have to pre-generate it)
pop in and out of different contexts
syntax highlighting
gist integration
view and replay history
open editors to edit methods using edit obj.my_method syntax
A tonne more great and original features
you can use ruby-debug to get access to irb
require 'rubygems'
require 'ruby-debug'
x = 23
puts "welcome"
debugger
puts "end"
when program reaches debugger you will get access to irb.
apparently it requires a chunk of code to drop into irb.
Here's the link (seems to work well).
http://jameskilton.com/2009/04/02/embedding-irb-into-your-ruby-application
require 'irb'
module IRB
def self.start_session(binding) # call this method to drop into irb
unless #__initialized
args = ARGV
ARGV.replace(ARGV.dup)
IRB.setup(nil)
ARGV.replace(args)
#__initialized = true
end
workspace = WorkSpace.new(binding)
irb = Irb.new(workspace)
#CONF[:IRB_RC].call(irb.context) if #CONF[:IRB_RC]
#CONF[:MAIN_CONTEXT] = irb.context
catch(:IRB_EXIT) do
irb.eval_input
end
end
end
This feature is available from Ruby 2.4. You can just use binding.irb
E.g.
require 'irb'
a = 10
binding.irb
puts a
If you run above code, you will get irb console, so that you can inspect values of local variables and anything else that is in scope.
Source: http://blog.redpanthers.co/new-binding-irb-introduced-ruby-2-4/
Ruby commit: https://github.com/ruby/ruby/commit/493e48897421d176a8faf0f0820323d79ecdf94a
Just add this line to where you want the breakpoint:
require 'ruby-debug';debugger
but i suggest use pry instead of irb, which is super handy, insert the following line instead:
require 'pry'; binding.pry
I'm quite late to the game but if you're loading a script from within irb/pry already, a simple raise also works to pop you back out to the irb/pry prompt. I use this quite often when writing one off scripts within the rails console.