I was working with the lotrepls Ruby interpreter, and I want like to write tests in the interpreter that I can then write Ruby code to pass. In Python, I can write doctests and then write code to pass the doctests. For example:
>>> b
1
This tests that b=1, and entering b=1 will get this doctest to pass.
Is there a similar way to write tests in a Ruby interpreter, execute them, write code to pass the tests, and then execute the test again? Is there a Ruby doctest equivalent? For my application, I will execute tests and code in a hosted interpreter like lotrepls rather than install something on my local machine.
There's RubyDocTest, but I'd encourage you to look at something like RSpec or another modern BDD/TDD framework.
It's pretty easy to write tests there too, and you get access to complex and/or custom assertions that you can't really get in a doctest. For instance, here's a simple set of tests for a baseball scoring app:
describe BaseballScorer do
before :each do
#s = Scorer.new(Game.new)
end
it "should score a 0-0 game when no runs are hit" do
#s.home.score.should == #s.away.score.should == #s.total_runs
end
it "should record runs that are hit" do
#s.game.run_hit(:away)
#s.away.runs.should == #s.away.score.should == 1
end
# ...
This is a little old post but I faced the same problem some months ago.
John's answer is correct but if you want to use something similar to a irb session you could try byexample, in particular it supports Ruby
For example you can write a Markdown doc like this:
This is an awesome expression:
```ruby
>> 1 + 2
=> 3
```
Then you just run from the shell
$ byexample -l ruby your-markdown-doc.md
[PASS] Pass: 1 Fail: 0 Skip: 0
You could also embed the test inside a Ruby comment like
# square 2
# => 4
def square x
x * x
end
And that's it. The example is executed and checked so your doc works as regression test as well.
Disclaimer: Like I said, I had the same desire to do TDD in Ruby so I wrote byexample. I really hope than others find it as much as useful and I do.
Related
I assume this is very newbie stuff but I'm learning Ruby by doing, and I'm developing a small CLI tool that receives a couple of parameters in order to do its stuff properly. This is my current workflow:
I want to test (using Minitest) all the possible flows:
Exits with 0 and help message is shown if ARGV.count != 2
Exits with 1 if first param is not correct
Exits with 1 if second param is not correct
Exits with 1 if both params are not correct
Exits with 0 and does stuff if all params are correct
Now, if I run tests the only thing I see is the help output as there is no parameter being passed.
So, a couple of questions:
How can I pass arguments to the main program in tests?
How can I test the output? (I'm using puts)
Thanks!
nice diagram!
you can either use helpers like aruba https://github.com/cucumber/aruba
or dig into ruby internals in order to bend it to your will!
# test.rb
pseudoIO = StringIO.new
$stdout = pseudoIO
puts "hi #{ARGV.join(', ')}"
ARGV.replace ["file1"]
puts "now its #{ARGV.join(', ')}"
abort "captured: #{pseudoIO.string}"
output should be
ruby text.rb "whutup"
# => captured: hi whutup
# => now its file1
I'm writing some tests for a webpage that I'd like to run in several environments. The idea is that the test will run in one, then repeat in the next. The two environments are preview and uat.
I've written an Around hook to set the environment variables. Below:
Around do |scenario, block|
def test_envs
chosen_env = ENV['test_env'] || 'preview'
chosen_env.split(',').map(&:strip)
end
test_envs.each do |test_env|
$base_url = "https://#{test_env}.webpage.com"
end
block.call
end
I have then written a method to execute the navigation step:
def navigate_to(path)
visit $base_url + path
end
My Scenario step_definition is:
navigate_to '/login'
The tests will work in either environment, Preview by default or UAT if I set test_env=uat
However, I was aiming to set test_env=preview,uat and have them run consecutively in both environments.
Is there something obvious that I've missed here?
Thanks
If I'm understanding you correctly, it's the 'parallel' aspect that you're asking about.
Rspec can be used with parallel tests (the parallel_tests gem) but I wouldn't be so sure that calling something like 3.times { blk.call } in an around hook will run each block in parallel.
An alternative may be do so some metaprogramming with your example definitions, i.e.
test_envs.each do |env_name|
it "does something in #{env_name}" do
# do something with the specific environment
end
end
Now, I haven't actually used this gem and I don't know for sure it would work. I think the simplest solution may be to just write a wrapper script to call the tests
# run_tests.rb
environments = ENV["TEST_ENV"]&.split(",") || []\
filename = ENV["filename"]
environments.each do |env_name|
Thread.new do
system <<-SH
env TEST_ENV=#{env_name} bundle exec rspec #{filename}
SH
end
end
Running it like env TEST_ENV=foo,bar ruby run_tests.rb would call the following commands in their own threads:
env TEST_ENV=foo bundle exec rspec
env TEST_ENV=bar bundle exec rspec
I like this approach because it means you don't have to touch your existing test code.
I have been trying to use the minitest-reporters gem to alter the output style of Ruby's builtin minitest testing library. However, it does not actually change the output.
It should be noted that I am not using Rails or Rake, but I didn't think that would make a difference. I am simply trying to test a Ruby command-line program that I have written.
Here's a dumb little test case (let's call it dumbtest.rb) that I was trying out:
require 'minitest/autorun'
require 'minitest/reporters'
Minitest::Reporters.use! [Minitest::Reporters::DefaultReporter.new(:color => true), Minitest::Reporters::SpecReporter.new]
describe "MiniTest demo" do
describe "when asked about the number 2" do
it "should be equal to the number 2" do
2.must_equal 2
end
end
end
When I run the test, it just produces the default minitest output (i.e. colorless, no descriptions of passing tests, etc.):
$ ruby -Ilib:test dumbtest.rb
Run options: --seed 48983
# Running:
.
Finished in 0.001356s, 737.6595 runs/s, 737.6595 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
With minitest-reporters enabled, I expect the output to look something more like this (i.e. list both passing and failing tests as opposed to just failing, the word PASS is colored green, the final summary is color-coded, etc.):
There are no runtime errors. It's just not working for me. Any idea why?
I am trying to run a very basic test with Terminal and Sublime Text 3. My simple test runs, but fails (undefined local variable or method 'x')
My folder hierarchy looks like this:
spec_helper.rb looks like this:
require_relative '../test'
require 'yaml'
test_spec.rb is extremely basic
require 'spec_helper.rb'
describe "testing ruby play" do
it "finds if x is equal to 5" do
x.should eql 5
end
end
and my test.rb file has x = 5 That's it.
Will a variable only be recognizable if it's part of a class? And do I need to call a new class every time I run my test?
From the docs
require(name) → true or false
Loads the given name, returning true if successful and false if the feature is already
loaded.
[snip]
Any constants or globals within the loaded source file will be
available in the calling program’s global namespace. However, local
variables will not be propagated to the loading environment.
You could use a constant in your required file:
X = 5
...
X.should eql 5 # => passes
But you probably want to do something entirely different here. Perhaps you could expand on the question and explain what you are trying to accomplish.
Can I replace an executable (accessed via a system call from ruby) with an executable that expects certain input and supplies the expected output in a consistent amount of time? I'm mainly operating on Mac OSX 10.6 (Snow Leopard), but I also have access to Linux and Windows. I'm using MRI ruby 1.8.7.
Background: I'm looking at doing several DNA sequence alignments, one in each thread. When I try using BioRuby for this, either BioRuby or ruby's standard library's tempfile sometimes raise exceptions (which is better than failing silently!).
I set up a test that reproduces the problem, but only some of the time. I assume the main sources of variability between tests are the threading, the tempfile system, and the executable used for alignment (ClustalW). Since ClustalW probably isn't malfunctioning, but can be a source of variability, I'm thinking that eliminating it may aid reproducibility.
For those thinking select isn't broken - that's what I'm wondering too. However, according to the changelog, there was concern about tempfile's thread safety in August 2009. Also, I've checked on the BioRuby mailing list whether I'm calling the BioRuby code correctly, and that seems to be the case.
I really don't understand what the problem is or what exactly are you after, can't you just write something like
#!/bin/sh
#Test for input (syntax might be wrong, but you get the idea)
if [ $* ne "expected input" ]; then
echo "expected output for failure"
exit -1
fi
#have it work in a consistent amount of time
$CONSISTENT_AMOUNT_OF_TIME = 20
sleep $CONSISTENT_AMOUNT_OF_TIME
echo "expected output"
You can. In cases where I'm writing a functional test for program A, I may need to "mock" a program, B, that A runs via system. What I do then is to make program B's pathname configurable, with a default:
class ProgramA
def initialize(argv)
#args = ParseArgs(argv)
#config = Config.new(#args.config_path || default_config_path)
end
def run
command = [
program_b_path,
'--verbose',
'--do_something_wonderful',
].join(' ')
system(command)
...
end
def program_a_path
#config.fetch('program_b_path', default_program_b_path)
end
end
Program A takes a switch, "--config PATH", which can override the default config file path. The test sets up a configuration file in /tmp:
program_b_path: /home/wayne/project/tests/mock_program_b.rb
And passes to program A that configuration file:
program_a.rb --config /tmp/config.yaml
Now program A will run not the real program B, but the mock one.
Have you tried the Mocha gem? It's used a lot for testing, and you describe it perfectly. It "fakes" the method call of an object (which includes just about anything in ruby), and returns the result you want without actually running the method. Take this example file:
# test.rb
require 'rubygems'
require 'mocha'
self.stubs(:system).with('ls').returns('monkey')
puts system('ls')
Running this script outputs "monkey" because I stubbed out the system call. You can use this to bypass parts of an application you don't want test, to factor out irrelevant parts.