I require some files in features/support/env.rb as:
['/helpers/*', '/pages/*', '/models/*'].each do |path|
Dir[File.dirname(__FILE__) + path].each { |file| require file }
end
(I do it as I'd want to create test users and some other stuff before any of my tests are run.)
But it seems those files are then loaded by Cucumber using load as I get a ton of warnings like when Cucumber loads them:
/home/andrey/dev/project/features/support/models/my_class.rb:2: warning: already initialized constant MyClass::MY_CONSTANT
when scenarios start. How can I get rid of those warnings?
You can wrap your code in a silence_warnings block:
silence_warnings do
['/helpers/*', '/pages/*', '/models/*'].each do |path|
Dir[File.dirname(__FILE__) + path].each { |file| require file }
end
end
There's probably a better way to to whatever it is that you're trying to do, in a way that will play nice with your test framework, but the code above should handle your immediate question.
You probably can setup your helpers and models in a cucumber Before hook.
The recommended way to run a before hook only once is to use a global variable, so:
Before do
if !$already_required
['/helpers/*', '/pages/*', '/models/*'].each do |path|
Dir[File.dirname(__FILE__) + path].each { |file| require file }
end
$already_required = true
end
end
(https://github.com/cucumber/cucumber/wiki/Hooks#running-a-before-hook-only-once)
Related
I've been looking all around and didn't found any kind of answer to the problem i'm facing in Ruby. I'm writing an app that use core modules sets that are available in different versions. If I'm sourcing a core set version after an another one both code version will be sourced at the same and will clash with each other. That is quite normal and I'm ok with this.
One approach could be to unload the previous version to load the new one but I'd like to keep all the ones loaded into specific namespaces (to avoid time consuming to unload/reload code all the time). 2 possible solutions to me (or maybe other)
Either source the code then move it into a version namespace (some clues to do it see below but doesn't work yet)
Or source the code directly into a version namespace (don't know how to do it exactly, maybe with module_eval but need to recode the require process with dependencies). Does any solution seems possible ?
Here is a very simple poc of what I'm trying to achieve
file : coreset_1.0.0.rb
module CoreA
def self.who_am_i?; self.to_s; end
def self.get_coreb; CoreB end
end
module CoreB
def self.who_am_i?; self.to_s; end
end
file : coreset_2.0.0.rb (got some changes)
module CoreA
def self.my_name; self.to_s; end
def self.get_coreb; CoreB end
end
module CoreB
def self.my_name; self.to_s; end
end
file : coreManager.rb
module CoreManager
def self.load_version(arg_version)
#Create a module set for the selected version
core_set_name = CoreSet + '_' + arg_version.gsub('.', '_')
core_set = eval("Module #{core_set_name}; end; #{core_set_name}"
#Load the requested code
require "coreset_#{arg_version}.rb"
#Move loaded code into it core set module
core_set.const_set(:CoreA, Object.send(:remove_const, :CoreA))
core_set.const_set(:CoreB, Object.send(:remove_const,:CoreB))
#Return the created core set
core_set
end
end
If running the code :
require 'coreManager.rb'
core_set = CoreManager.load_version("1.0.0")
puts core_set::CoreA.who_am_i?
puts core_set::CoreA.get_coreB
it returns :
CoreA #not CoreSet_1_0_0::CoreA
uninitialized constant CoreA::CoreB (NameError)
If running something statically defined, it works
module CoreSet
module CoreA
def self.who_am_i?; self.to_s; end
def self.get_coreb; CoreB end
end
module CoreB
def self.who_am_i?; self.to_s; end
end
end
CoreSet::CoreA.get_coreb
It returns as expected :
CoreSet::CoreB
Depite of what is usually said :"a module is a constant", it seems to be more than that. What are the differencies and how to make the dynamic version working ?
Any other ideas ?
Thanks for your help folks :)
There are several things broken in your code (which is ok for POC, I guess), but the main one is that require loads constants and globals into the global namespace.
So, your Core<X> modules are not namespaced this way, as you might expect. There is Kernel#load method that allows "wrapped" execution of the loaded file, but it's wrapped into an anonymous module, so you can prevent the global namespace from being polluted, but you cannot "target" the constants to be defined into a particular namespace this way.
What you could try is to load the code as text and then eval it within the dynamically created module, matching your version. For example, look at this quick and very dirty sketch (coreset_...rb files are expected to sit into coresets directory):
module CoreSet; end
class CoreManager
class << self
def load_version(ver)
raise "Vesion #{ver} unknown" unless exists?(ver)
file = filename(ver)
code = File.read(file)
versioned_wrapper = Module.new do
class_eval code
end
CoreSet.const_set("V_#{ver.gsub('.', '_')}", versioned_wrapper)
end
private
def exists?(ver)
File.exists? filename(ver)
end
def filename(ver)
"coresets/coreset_#{ver.gsub('.', '_')}.rb"
end
end
end
CoreManager.load_version("1.0.0")
CoreManager.load_version("2.0.0")
p CoreSet::V_1_0_0::CoreA.who_am_i? # => "CoreSet::V_1_0_0::CoreA"
p CoreSet::V_1_0_0::CoreA.get_coreb # => CoreSet::V_1_0_0::CoreB
p CoreSet::V_2_0_0::CoreA.my_name # => "CoreSet::V_2_0_0::CoreA"
p CoreSet::V_2_0_0::CoreA.get_coreb # => CoreSet::V_2_0_0::CoreB
But, DON'T do this at home, please :) At least, I would think twice.
If all you need is to have all the versions loaded at once (you need namespaces exactly for this, right?) what stops you from defining them statically, like CoreSet::V1::Core<X> etc and use the idiomatic and safe ways to (auto)load them? :) Playing with dynamic nested constants definition (and, especially, their removing) is one of the easiest ways to shoot your own foot...
Ok I finally came to a solution that may help others or that can be discussed.
Getting the error uninitialized constant CoreA::CoreB (NameError) leads me to take the problem under a new angle. If I'm not able to access to CoreB module from CoreA (because the module nesting has been broken when redefining module constants into the CoreSet module) then why not referencing in each core module the other ones in the set ? And finaly it works without any dirty hack, I'm just creating pointers and the Ruby Core find it natively ;)
module CoreManager
def self.load_version(arg_version)
#Create a module set for the selected version
core_set_name = CoreSet + '_' + arg_version.gsub('.', '_')
core_set = eval("Module #{core_set_name}; end; #{core_set_name}"
#Load the requested code
toplevel_consts = Object.constants
require "coreset_#{arg_version}.rb"
core_modules = Object.constants - toplevel_consts
#Move the core modules to the set namespace
core_modules.collect! do |core_module|
core_module_sym = core_module.to_s.to_sym
core_set.const_set(core_module_sym, Object.send(:remove_const, core_module_sym))
eval("#{core_set}::#{core_module}")
end
#Create connexion between set cores to skirt broken module nesting
core_modules.each do |current_core|
core_modules.each do |other_core|
current_core.const_set(other_core.to_s.to_sym, other_core) unless current_core == other_core
end
end
#Return the created core set
core_set
end
end
I am trying to create a test for a FileProcessor that reads from a text file, passes it to another class and then writes output. I made a test file and am able to access but it feels bulky. I'm also going to need to test that it writes the output in a new file and I am not sure how to set this up. I've seen a lot of tutorials but they are be rails centric. My goal is to get rid of writing the path in the test and to clean up the generated output files after each test.
describe FileProcessor do
test_file = File.dirname(__FILE__) + '/fixtures/test_input.txt'
output_file = File.dirname(__FILE__) + '/fixtures/test_output.txt'
subject {FileProcessor.new(test_file, output_file)}
describe '#read_file' do
it 'reads a file' do
expect(subject.read_file).to eq('This is a test.')
end
end
def write_file(str)
File.open("#{output_file}", "w+") { |file| file.write(str) }
end
end
How about using StringIO:
require 'stringio'
class FileProcessor
def initialize(infile, outfile)
#infile = infile
#outfile = outfile
#content = nil
end
def read_file
#content ||= #infile.read
end
def write_file(text)
#outfile.write(text)
end
end
describe FileProcessor do
let(:outfile) { StringIO.new }
subject(:file_processor) do
infile = StringIO.new('This is a test')
FileProcessor.new(infile, outfile)
end
describe '#read_file' do
it "returns correct text" do
expect(file_processor.read_file).to eq("This is a test")
end
end
describe '#write_file' do
it "writes correct text" do
file_processor.write_file("Hello world")
outfile.rewind
expect(outfile.read).to eq("Hello world")
end
end
end
There's not a great way to avoid writing the path of your input file. You could move that into a helper method, but on the other hand having the path in the test has the benefit that someone else (or you six months from now) looking at the code will know immediately where the test data comes from.
As for the output file, the simplest solution is to use Ruby's built-in Tempfile class. Tempfile.new is like File.new, except that it automatically puts the file in /tmp (or wherever your OS's temporary file directory is) and gives it a unique name. This way you don't have to worry about cleaning it up, because the next time you run the test it'll use a file with a different name (and your OS will automatically delete the file). For example:
require 'tempfile'
describe FileProcessor do
let(:test_file_path) { File.dirname(__FILE__) + '/fixtures/test_input.txt' }
let(:output_file) { Tempfile.new('test_output.txt').path }
subject { FileProcessor.new(test_file_path, output_file.path) }
describe '#read_file' do
it 'reads a file' do
expect(subject.read_file).to eq('This is a test.')
end
end
end
Using let (instead of just assigning a local variable) ensures that each example will use its own unique output file. In RSpec you should almost always prefer let.
If you want to get really serious, you could instead use the FakeFS gem, which mocks all of Ruby's built-in file-related classes (File, Pathname, etc.) so you're never writing to your actual filesystem. Here's a quick tutorial on using FakeFS: http://www.bignerdranch.com/blog/fake-it/
I'm trying to define a few let's and before hooks that will run globally for all my specs by including them in a separate file using the Rspec configuration block.
I tried something like:
module Helpers
def self.included(base)
base.let(:x){ "x" }
base.before(:all){ puts "x: #{x}" }
end
end
Rspec.configure{|c| c.include Helpers }
but this doesn't work as expected. The before(:all) doesn't just run before each main example group, but each nested one as well.
Then I found out about shared_context and it appears to be exactly what I want.
My open problem however is that I can't figure out how to share a context amongst ALL of my specs. The docs only reference include_context within a specific spec.
Can anyone tell me how I can achieve this behavior in a global manner? I'm aware that I can define global before hooks in my spec_helper but I can't seem to use let. I'd like a single place that I can define both of these things and not pollute my spec helper, but just include it instead.
I tried to reproduce your error, but failed.
# spec_helper.rb
require 'support/global_helpers'
RSpec.configure do |config|
config.include MyApp::GlobalHelpers
end
# support/global_helpers.rb
module MyApp
module GlobalHelpers
def self.included(base)
base.let(:beer) { :good }
base.before(:all) { #bottles = 10 }
end
end
end
# beer_spec.rb
require 'spec_helper'
describe "Brewery" do
it "makes good stuff" do
beer.should be :good
end
it "makes not too much bottles" do
#bottles.should == 10
end
context "when tasting beer" do
before(:all) do
#bottles -= 1
end
it "still produces good stuff" do
beer.should be :good
end
it "spends some beer on degusting" do
#bottles.should == 9
end
end
end
https://gist.github.com/2283634
When I wrote something like base.before(:all) { p 'global before'; #bottles = 10 }, I got exactly one line in spec output.
Notice that I didn't try to modify instance variables inside an example, because it wouldn't work anyway (well, actually you can modify instance variables, if it's a hash or array). Moreover, even if you change before(:all) in nested example group to before(:each), there will be still 9 bottles in each example.
I am working on a program in Ruby with Watir that has a series of modules.
An example module would look like:
demoMod1.rb
DEMOMOD1 = true #this module has been loaded
module demoMod1
def reload(browser)
browser.goto("demo1.html")
end
end
There are several files with very similarly named functions (example: reload() ), so demoMod2 and demoMod3 both have the same reload function (except pointing to different pages).
The modules are commented out of the require list when that area is not expected to be tested. (as per design specs)
The program then dynamically loads test case files (code to do that is below in main.rb). Each test case file contains a runTest() function, which calls the appropriate sections from the modules. Each test checks if the module is loaded, and if it has, the test executes.
A sample test case file would look like:
test1.rb
def runTest(browser) # test case 1
if(defined?(DEMOMOD1)).nil?
return nil #if the module is not there, dont run this test
end
demoMod1::reload(browser)
end
As per specs, a single file lists all of the modules to be required, so that a user can just comment out the sections to not be tested without having to look at the main file. The main file is below.
main.rb
require 'Watir'
SITE = #internal site - address removed =/ sorry
FOLDER = File.dirname(__FILE__) + '/lib'
SHORTNAME = 'Test' #for reporting
LONGNAME = 'In Development' #for reporting
#I know - globals.. yuck... avoid...
require FOLDER + '/lib/requires'
#includes the function to require each module from the module folder
require FOLDER + '/www/include/report.module'
#creates an html report to view the test results
# Get list of tests
def getTests()
Dir.chdir(FOLDER + '/Tests')
files = Dir.glob("*.rb")
return files
end #eofunc
# Run each test
def runTests(files, browser, report)
testSuite = String.new
files.each do |test|
suite = test.split(" - ") # name convention: suite - testname.rb
if !(suite[0]==testSuite)
testSuite = suite[0]
report.newTestSuiteName(testSuite)
end #eoif
load FOLDER + '/Tests/' + test #load the test case file
runTest(browser) #run the test case
end #eoeach
end #eofunc
begin
browser = Watir::Browser.new
browser.goto(SITE)
report = Report.new()
reportname = report.createReport(SHORTNAME, LONGNAME) #vars in Vars.rb
files = getTests()
runTests(files, browser, report)
report.finishReport(reportname, SITE)
browser.close
report.openReport(reportname) #launch report in a new browser
end #eofunc
I would expect in each of the runTest() to be able to access the demoMod1::reload() and demoMod2::reload(), but this is not the case. I get an error for undefined method 'reload' for demoMod1:Module. I can resolve the error by using include demoMod1 but then (if I have this correctly), the scope is not needed, and using just reload() would work. However this would require each module have entirely unique names, and that is not a great solution.
What am I missing?
Have you tried using a Test/Unit / rSpec or something similar to run your tests?
Beyond that, my understanding is:
Requiring the file the module is in only makes it available for inclusion. You need to use include to put it into a class in order to use it.
Have you considered making a class for your tests, e.g. Test and then TestType1 and TestType2 inheriting from that parent class?
For example:
require fileWithYourModules
class Test
# stuff I want to have available to all tests
end
class TestSubType1 < Test
include demoMod1
end
class TestSubType2 < Test
include demoMod2
end
Which then allows you to call the same method name and have it behave differently depending on the test class it has.
I'm sure there are more elegant solutions, I'm just a tester and not a programmer! :)
By changing the function names in the modules I can get it to work.
example module:
DEMOMOD1 = true
module DemoMod1
def DemoMod1.reload(browser) #<---------
browser.goto('demo1.htm')
end
end
Line with the <--- arrow is the main change (also had to change the module name, did not have a capital first letter...oops)
example test case:
def runTest(browser) # test case 1
if(defined?(DEMOMOD1)).nil?
return nil #if the module is not there, dont run this test
end
DemoMod1::reload(browser)
### OR ### Both work
DemoMod1.reload(browser)
end
I'm writing a sinatra app and testing it with rspec and rack/test (as described on sinatrarb.com).
It's been great so far, until I moved some rather procedural code from my domain objects to
sinatra helpers.
Since then, I've been trying to figure out how to test these in isolation ?
I test my sinatra helpers in isolation by putting the helper methods within its own module.
Since my sinatra application is a little bit bigger than the usual hello world example, I need to split it up into smaller parts. A module for the common helpers suits my use case well.
If you write a quick demo, and you define your helper methods within the helpers { ... } block, I don't think testing it is absolutely necessary. Any sinatra app in production, may require more modularity anyways.
# in helpers.rb
module Helpers
def safe_json(string)
string.to_s.gsub(/[&><']/) { |special| {'&' => '\u0026', '>' => '\u003E', '<' => '\u003C', "'" => '\u0027'}[special] }
end
end
# in app.rb
helpers do
include Helpers
end
# in spec/helpers_spec.rb
class TestHelper
include Helpers
end
describe 'Sinatra helpers' do
let(:helpers) { TestHelper.new }
it "should escape json to inject it as a html attribute"
helpers.safe_json("&><'").should eql('\u0026\u003E\u003C\u0027')
end
end
Actually you don't need to do:
helpers do
include FooBar
end
Since you can just call
helpers FooBar
The helpers method takes a list of modules to mix-in and an optional block which is class-eval'd in: https://github.com/sinatra/sinatra/blob/75d74a413a36ca2b29beb3723826f48b8f227ea4/lib/sinatra/base.rb#L920-L923
maybe this can help you some way http://japhr.blogspot.com/2009/03/sinatra-innards-deletgator.html
I've also tried this (which needs to be cleaned up a bit to be reusable) to isolate each helper in its own environment to be tested:
class SinatraSim
def initialize
...set up object here...
end
end
def helpers(&block)
SinatraSim.class_eval(&block)
end
require 'my/helper/definition' # defines my_helper
describe SinatraSim do
subject { SinatraSim.new(setup) }
it "should do something"
subject.expects(:erb).with(:a_template_to_render) # mocha mocking
subject.my_helper(something).should == "something else"
end
end