I'm using an external API that takes a key string, and would like to pass this key string to the test suite. Something like:
rake test [key=api_key]
The code together with the tests will be open sourced, but I'm not allowed to distribute my key string to other users, so I cannot put it in the test file. Can I pass it as a parameter?
You have two options. Pass it as an environment variable:
API_KEY='key' rake test
You can then access this through the ENV object in your test:
key = ENV['API_KEY']
Second option is to put this key in a file (e.g. key.txt) and you read it from that. To ensure that you don't distribute that file with your code, add it to your .gitignore file (or whatever is the ignore file used by your SCM)
Thank you very much!
I actually was thinking of putting it into a file and gitignoring it, but ended up passing a parameter to rake. May be, I will combine both (it's a long key).
Modify the Rakefile code for the :test task, such as adding a
parameter to it.
task :test, :key do |t, k|
result = system("ruby -Ilib -Itest -e 'ARGV.each { |f| load(f) if File.exists?(f)}' test/unit/* '#{k[:key]}'")
exit(result ? 0 : 1)
end
Call rake test['blah-blah']
It may take more then one key if needed.
Related
According to this piece of documentation, it is possible to achieve the following output format by selecting the format documentation:
something
does something that passes
does something that fails (FAILED - 1)
does something that is pending (PENDING: Not Yet Implemented)
Is it possible to slightly edit this so it outputs as:
something
does something (SUCCESS)
does something (FAIL)
does something (PENDING)
Basically I would like the result of the test displayed no matter what - instead of just logging explicitly the failures and the pending ones.
I was able to do this by subclassing RSpec::Core::Formatters::DocumentationFormatter. Create the following file as spec/formatters/custom_formatter.rb:
class CustomFormatter < RSpec::Core::Formatters::DocumentationFormatter
RSpec::Core::Formatters.register self
private
def passed_output(example)
format_output(example, 'SUCCESS', :success)
end
def pending_output(example, _message)
format_output(example, 'PENDING', :pending)
end
def failure_output(example)
format_output(example, 'FAILED', :failure)
end
def format_output(example, status_text, code_or_symbol)
RSpec::Core::Formatters::ConsoleCodes.wrap(
"#{current_indentation}#{example.description.strip} (#{status_text})",
code_or_symbol
)
end
end
Then run the specs using this:
rspec --require formatters/custom_formatter --format CustomFormatter
Instead of --require formatters/custom_formatter, you can also require the formatter on spec/spec_helper.rb, e.g.
require_relative 'formatters/custom_formatter'
Then you only need to run this:
rspec --format CustomFormatter
If you want CustomFormatter to be the default formatter, you can add the command line options to .rspec configuration file at your project root. Here's how it should look like:
--require spec_helper
--require /path/to/custom_formatter.rb
--format CustomFormatter
With that, you no longer need to specify any command line arguments to use CustomFormatter.
Documentations and references:
https://relishapp.com/rspec/rspec-core/v/3-6/docs/formatters/custom-formatters
http://www.rubydoc.info/gems/rspec-core/RSpec/Core/Formatters
https://github.com/rspec/rspec-core/blob/v3.7.0/lib/rspec/core/formatters/documentation_formatter.rb
You can not change the existing RSpec formatters, but you can create your own
When RSpec's built-in output formatters don't, however, give you everything
you need, you can write your own custom formatter and tell RSpec to use that
one instead. The simplest way is to subclass RSpec's BaseTextFormatter, and
then override just the methods that you want to modify.
I'm building a test suite to teach OOP. I want the files in my spec/lib folder to be executed in a specific order.
I would like to define an array of class names, and their test suite would be executed in order. For example:
spec_order = %w(
FirstClass
SecondClass
ThirdClass
)
How might I accomplish this?
Name the _spec.rb files numerically:
01_first_spec.rb
02_second_spec.rb
...
Create a .rspec file
# .rspec
--order defined
Now, when running rspec the files should be executed in sorted order.
Ordering tests is not recommended by almost all testing frameworks. That is part of making sure that tests are independent and don't yield unexpected behavior when order changes.
However, if you want to run test files in specific order then you can accomplish that by writing scripts:
1. Shell Script
Consider the following script (ordered_test_script.sh):
for f in file1_spec.rb file2_spec.rb file3_spec.rb
do
rspec $f
done
Make sure the script is executable:
chmod +x ordered_test_script.sh
Then you can run the script:
./ordered_test_script.sh
2. Ruby Script
First, you might want to extend the String class to include an underscore method:
class String
def underscore
self.gsub(/::/, '/').
gsub(/([A-Z]+)([A-Z][a-z])/,'\1_\2').
gsub(/([a-z\d])([A-Z])/,'\1_\2').
tr("-", "_").
downcase
end
end
This will turn camelcase class names to underscore ones. For example (MyClass => my_class)
classes = %w(MyClass1 MyClass2 MyClass3)
classes.each do |c|
system("rspec #{c.to_s.underscore}_spec.rb")
end
Hope this helps.
Of course it's good practice to have randomization by default, but in some cases, such as when trying to track down order-related issues in your specs, or for documentation generation, it might be nice to specify a temporary order.
You can specify a "global" ordering for some (or all) of your spec files as follows:
config.register_ordering(:global) do |items|
files = <<END.split("\n")
./spec/some_spec.rb
./spec/another_spec.rb
END
# Original RSpec random order
randomized = RSpec::Core::Ordering::Random.new(config).order(items)
# Now do a stable sort by filename index
randomized.sort_by.with_index do |example_group, index|
files.index(example_group.file_path) || files.size + index
end
end
Documentation for register_ordering is available on Relish.
I have to maintain a Ruby script, which requires some libs I don't have locally and which won't work in my environment. Nevertheless I want to spec some methods in this script so that I can change them easily.
Is there an option to stub some of the require statements in the script I want to test so that it can be loaded by rspec and the spec can be executed within my environment?
Example (old_script.rb):
require "incompatible_lib"
class Script
def some_other_stuff
...
end
def add(a,b)
a+b
end
end
How can I write a test to check the add function without splitting the "old_Script.rb" file and without providing the incompatible_lib I don't have?
Instead of stubbing require which is "inherited" from Kernel, you could do this:
Create a dummy incompatible_lib.rb file somewhere that is not in your $LOAD_PATH. I.e., if this is a Ruby application (not Rails), don't put it in lib/ nor spec/.
You can do this a number of ways, but I'll tell you one method: in your spec file which tests Script, modify $LOAD_PATH to include the parent directory of your dummy incompatible_lib.rb.
Ordering is very important -- next you will include script.rb (the file which defines Script).
This will get you around the issue and allow you test test the add method.
Once you've successfully tested Script, I would highly recommend refactoring it so that you don't have to do this technique, which is a hack, IMHO.
Thanks, I also thought about the option of adding the files, but finally hacked the require itself within the test case:
module Kernel
alias :old_require :require
def require(path)
old_require(path) unless LIBS_TO_SKIP.include?(path)
end
end
I know that this is an ugly hack but as this is legacy code executed on a modified ruby compiler I can't easily get these libs running and it's sufficient to let me test my modifications...
i would like to show you my use case and then discuss possible solutions:
Problem A:
i have 2 recipes, "a" and "b".. "a" installs some program on my file system (say at "/usr/local/bin/stuff.sh" and recipe "b" needs to run this and do something with the output.
so recipe "a" looks something like:
execute "echo 'echo stuff' > /usr/local/bin/stuff.sh"
(the script just echo(es) "stuff" to stdout)
and recipe "b" looks something like:
include_recipe "a"
var=`/usr/local/bin/stuff.sh`
(note the backquotes, var should contain stuff)
and now i need to do something with it, for instance create a user with this username. so at script "b" i add
user "#{node[:var]}"
As it happens, this doesn't work.. apparently chef runs everything that is not a resource and only then runs the resources so as soon as i run the script chef complains that it cannot compile because it first tries to run the "var=..." line at recipe "b" and fails because the "execute ..." at recipe a did not run yet and so the "stuff.sh" script does not exist yet.
Needless to say, this is extremely annoying as it breaks the "Chef runs everything in order from top to bottom" that i was promised when i started using it.
However, i am not very picky so i started looking for alternative solutions to this problem, so:
Problem B: i've run across the idea of "ruby_block". apparently, this is a resource so it will be evaluated along with the other resources. I said ok, then i'd like to create the script, get the output in a "ruby_block" and then pass it to "user". so recipe "b" now looks something like:
include_recipe "a"
ruby_block "a_block" do
block do
node.default[:var] = `/usr/local/bin/stuff.sh`
end
end
user "#{node[:var]}"
However, as it turns out the variable (var) was not passed from "ruby_block" to "user" and it remains empty. No matter what juggling i've tried to do with it i failed (or maybe i just didn't find the correct juggling method)
To the chef/ruby masters around: How do i solve Problem A? How do i solve Problem B?
You have already solved problem A with the Ruby block.
Now you have to solve problem B with a similar approach:
ruby_block "create user" do
block do
user = Chef::Resource::User.new(node[:var], run_context)
user.shell '/bin/bash' # Set parameters using this syntax
user.run_action :create
user.run_action :manage # Run multiple actions (if needed) by declaring them sequentially
end
end
You could also solve problem A by creating the file during the compile phase:
execute "echo 'echo stuff' > /usr/local/bin/stuff.sh" do
action :nothing
end.run_action(:run)
If following this course of action, make sure that:
/usr/local/bin exist during Chef's compile phase;
Either:
stuff.sh is executable; OR
Execute it through a shell (e.g.: var=`sh /usr/local/bin/stuff.sh`
The modern way to do this is to use a custom resource:
in cookbooks/create_script/resources/create_script.rb
provides :create_script
unified_mode true
property :script_name, :name_property: true
action :run do
execute "creating #{script_name}" do
command "echo 'echo stuff' > #{script_name}"
not_if { File.exist?(script_name) }
end
end
Then in recipe code:
create_script "/usr/local/bin/stuff.sh"
For the second case as written I'd avoid the use of a node variable entirely:
script_location = "/usr/local/bin/stuff.sh"
create_script script_location
# note: the user resources takes a username not a file path so the example is a bit
# strange, but that is the way the question was asked.
user script_location
If you need to move it into an attribute and call it from different recipes then there's no need for ruby_blocks or lazy:
some cookbook's attributes/default.rb file (or a policyfile, etc):
default['script_location'] = "/usr/local/bin/stuff.sh"
in recipe code or other custom resources:
create_script node['script_location']
user node['script_location']
There's no need to lazy things or use ruby_block using this approach.
There are actually a few ways to solve the issue that you're having.
The first way is to avoid the scope issues you're having in the passed blocks and do something like ths.
include_recipe "a"
this = self
ruby_block "a_block" do
block do
this.user `/usr/local/bin/stuff.sh`
end
end
Assuming that you plan on only using this once, that would work great. But if you're legitimately needing to store a variable on the node for other uses you can rely on the lazy call inside ruby to do a little work around of the issue.
include_recipe "a"
ruby_block "a_block" do
block do
node.default[:var] = `/usr/local/bin/stuff.sh`.strip
end
end
user do
username lazy { "#{node[:var]}" }
end
You'll quickly notice with Chef that it has an override for all default assumptions for cases just like this.
I want to be able to run a single spec file's tests — for the one file I'm editing, for example. rake spec executes all the specs. My project is not a Rails project, so rake spec:doc doesn't work.
Don't know if this matters, but here is my directory structure.
./Rakefile
./lib
./lib/cushion.rb
./lib/cushion
./lib/cushion/doc.rb
./lib/cushion/db.rb
./spec
./spec/spec.opts
./spec/spec_helper.rb
./spec/db_spec.rb
Or you can skip rake and use the 'rspec' command:
bundle exec rspec path/to/spec/file.rb
In your case I think as long as your ./spec/db_spec.rb file includes the appropriate helpers, it should work fine.
If you're using an older version of rspec it is:
bundle exec spec path/to/spec/file.rb
The raw invocation:
rake spec SPEC=spec/controllers/sessions_controller_spec.rb \
SPEC_OPTS="-e \"should log in with cookie\""
Now figure out how to embed this into your editor.
This question is an old one, but it shows up at the top of Google when searching for how to run a single test. I don't know if it's a recent addition, but to run a single test out of a spec you can do the following:
rspec path/to/spec:<line number>
where -line number- is a line number that contains part of your test. For example, if you had a spec like:
1:
2: it "should be awesome" do
3: foo = 3
4: foo.should eq(3)
5: end
6:
Let's say it's saved in spec/models/foo_spec.rb. Then you would run:
rspec spec/models/foo_spec.rb:2
and it would just run that one spec. In fact, that number could be anything from 2 to 5.
You can also use the actual text of the *e*xample test case with -e !
So for:
it "shows the plane arrival time"
you can use
rspec path/to/spec/file.rb -e 'shows the plane arrival time'
./scripts/spec path/to/spec/file.rb -e 'shows the plane arrival time'
no need for rake here.
from help (spec -h):
-l, --line LINE_NUMBER Execute example group or example at given line.
(does not work for dynamically generated examples)
Example: spec spec/runner_spec.rb -l 162
To run all of your rspec files: rspec
note: you must be in the root of your project
To run one rspec file: rspec 'path_to/spec.rb'
note: replace 'path_to/spec.rb' with your path. Quotation marks optional.
To run one rspec test from one file: rspec 'path_to/spec.rb:7'
note: :7 is the line number where the test starts
If you installed rspec as a plugin rather than as a gem, then you won't have the spec executable.
At any rate, All you need to do is run the file using ruby. The rspec code is clever enough to run the tests for you.
eg:
ruby myclass_spec.rb
http://github.com/grosser/single_test lets you do stuff like..
rake spec:user #run spec/model/user_spec.rb (searches for user*_spec.rb)
rake test:users_c #run test/functional/users_controller_test.rb
rake spec:user:token #run the first spec in user_spec.rb that matches /token/
rake test:user:token #run all tests in user_test.rb that match /token/
rake test:last
rake spec:last
Ruby 1.9.2 and Rails 3 have an easy way to run one spec file:
ruby -I spec spec/models/user_spec.rb
Explanation:
ruby command tends to be faster than the rake command
-I spec means "include the 'spec' directory when looking for files"
spec/models/user_spec.rb is the file we want to run.
Although many great answers were written to this question, none of them uses the Rspec tags approach.
I use tags to run one or more specs in different files -- only those related to my current development task.
For example, I add the tag "dev" with the value "current":
it "creates an user", dev: :current do
user = create(:user)
expect(user.persisted?).to be_truthy
end
then I run
bundle exec rspec . --tag dev:current
Different tags/values can be set in individual specs or groups.
I was having trouble getting any of these examples to work, maybe because the post is old and the commands have changed?
After some poking around I found this works:
rspec spec/models/user_spec.rb
That will run just the single file and provides useful output in the terminal.
specky.vim
Alternatively, have a look at autotest.
Running autotest in a command window will mean that the spec file will be executed whenever you save it. Also, it will be run whenever the file you are speccing is run.
For instance, if you have a model spec file called person_spec.rb, and a model file that it is speccing called person.rb, then whenever you save either of these files from your editor, the spec file will be executed.
Lets say, you're running test for creating todo. You can always run that specific todo spec code using the file crete_spec.rb file as below.
rspec/spec/features/controller/spec_file_name.rb
Example:
Creating rspec spec/features/todos/create_spec.rb
Editing rspec spec/features/todos/edit_spec.rb
Deleting rspec spec/features/todos/destroy_spec.rb
If you want to run all the specs in one single short.
rspec
If you want to run all the specs in a specific controller user this.
rspec/spec/feaures/controller_name
Example: rspec/spec/features/todos
Hope it gives you more understanding!
And you can run specific line into your test file
rspec spec/models/model_spec.rb:47