When I start up zeus, it does not offer zeus cucumber as one of the possible commands. Others seem to get this by default; At least I have seen a couple zeus write-ups that show the output from zeus start including zeus cucumber, and they don't say anything about that having been special or required extra configuration.
I don't really even know where to start to troubleshoot this; I have googled and searched here for "use cucumber with zeus." I get no setup discussions. The only results I get are from people who seem to take for granted that it should be there, and are investigating problems with it not functioning correctly.
You should use this custom plan file from Zeus. Save it as custom_plan.rb at the root of your application:
require 'zeus/rails'
# 1. Add the cucumber methods (below) to your custom plan (or take this file if
# you don't have an existing custom_plan).
#
# 2. Add the following line to the test_environment section of your zeus.json:
#
# "cucumber_environment": {"cucumber": []}
class CucumberPlan < Zeus::Rails
def cucumber_environment
::Rails.env = ENV['RAILS_ENV'] = 'test'
require 'cucumber/rspec/disable_option_parser'
require 'cucumber/cli/main'
#cucumber_runtime = Cucumber::Runtime.new
end
def cucumber(argv=ARGV)
cucumber_main = Cucumber::Cli::Main.new(argv.dup)
had_failures = cucumber_main.execute!(#cucumber_runtime)
exit_code = had_failures ? 1 : 0
exit exit_code
end
end
Zeus.plan = CucumberPlan.new
Related
I'm pretty new to cucumber automated testing. When I first started, a co-worker had set up everything for me on my computer, and (now that he's gone) I've run into a problem that I can't seem to figure out.
I'm using cucumber to test a web application. In the past when I run the script, an internet explorer pops up, and I can see each line of the script being executed.
I recently had to reinstall cucumber, ruby, watir, etc., and that internet explorer screen no longer pops up.
I installed Ruby 1.9.3, cucumber (gem install cucumber), watir (gem install watir). Am I missing something? Is it an extra plug in? The script still runs. However, instead of taking say 1 min + to run a 320 step script, it now takes 1.5 seconds. There are no error messages. When run from the command window, it literally looked like it just scrolled through the script instead of going through each step.
What is the pop up screen called anyways? A scenario screen? Output screen?
It was really difficult for me to look it up on google because I had no idea how to refer to that screen.
Any help is appreciated. and I realize I might not have described the problem well enough. Just leave a comment, and I can try to clarify it more.
Feature:
'To go to a webpage'
Scenario:
# ----------
# GO TO PAGE
# ----------
Given that I have gone to the Login page at "url"
#
# ----------
# LOG IN
# ----------
When I add "username" to the Username
When I add "password" to the Password
And click the Login button
Then "Welcome" should be mentioned on the page
script definitions:
require "rubygems"
require "watir"
puts "Browser is running..."
END {
puts "Closing browser..."
}
BEGIN {
puts "Starting browser..."
}
Given /^that I have gone to the Login page at "(.*)"$/ do |item|
#browser = Watir::IE.start(item)
lnk_found = 0
#browser.links.each do |lnk|
if lnk.id.to_s.matches("overridelink")
lnk_found += 1
end
end
if lnk_found > 0
#browser.link(:id, "overridelink").click
end
# puts "Watir Version: #{Watir::IE::VERSION}"
#browser.maximize
end
#
#
#
When /^I add "(.*)" to the Username$/ do |item|
#browser.text_field(:name, "loginName").set(item)
end
#
#
When /^I add "(.*)" to the Password$/ do |item|
#browser.text_field(:name, "passwd").set(item)
end
#
#
#
Then /^"(.*)" should be mentioned on the page$/ do |item|
if #browser.text.include?(item)
# puts "TEST PASSED. FOUND >#{item}<"
else
puts "*** TEST FAILED ***. >#{item}< was not found."
end
end
Directory Structure
Cucumber
Testing
lib
login.rb
login.feature
I don't know what exactly fixed it but after taking suggestions and advices from different people I basically uninstalled and reinstalled watir several times.
I also updated the code, took out "require 'rubygems'" and replaced Watir::IE.start with Watir::Browser.start.
It seems like the problem was the existing scripts I worked with was based off of older versions of watir/cucumber/ruby, so when I had to reinstall everything, the scripts were no longer compatible with newer versions of everything.
I have multiple ruby test cases for selenium-webdriver and all the files are sharing the same user name and password to login to my account. Is there a way to create a global file and include that file in these test cases instead of typing them over and over again, something like #include?
Here is the part of the code that needs to be shared between other test cases:
def setup
#driver = Selenium::WebDriver.for :firefox
#base_url = "http://localhost:3000/"
#driver.manage.timeouts.implicit_wait = 30
#verification_errors = []
#facebook_ID = "xxxxxxxxxx#xxx.xxx"
#facebook_password = "xxxxxxx"
#facebook_receiver_friend = "John Smith"
end
There are multiple ways to do it.
You could use
require 'setup'
where setup.rb is the common file that has all the setting up variables/functions.
You could also use a YAML file. More information here. Where all your config attributes can be defined.
Also put this is at the top of the file $:.unshift '.' . This is so that your test file can "discover" your setup.rb file which is routable from the home directory.
Note - Even though you will save the file as setup.rb you will require as only setup.
I got my answer:
eval File.open('setup.dat').read
This will insert what I have in setup.dat as a text wherever I need it.
I have a command line (NON-RAILS) application written in pure Ruby that I'm driving out through Cucumber and RSpec. It follows the typical application hierarchy of lib, bin, spec, and feature directories.
Up until now, I've followed the traditional process of writing a failing Cucumber feature/scenario, dropping down to RSpec to drive out the supporting lib files, then getting the scenario to pass.
Unfortunately, this doesn't seem to be as straight forward when driving out the main application entry point in "bin/my_application.rb". The main issue for me is that I'm not describing a class in RSpec, it's a sequential Ruby script for managing the application's classes and initialization via command line parameters and options.
"bin/my_application.rb" is just a small shell-executed wrapper for parsing command line options and passing them onto my main application class as initializer options. I'd still like to test the behavior of the bin script (e.g. MyApp.should_receive(option_a).with(parameter)).
Any suggestions/thoughts/advice? Is this a normal test strategy for driving out command line Ruby script behavior?
Thanks in advance.
Not sure I fully comprehend what you're asking, but I'd say that if you want to use RSpec to test your parameter passing it should be easy enough to do. Say you have your wrapper script:
# my_application.rb
command = Command.new
command.foo = true if ARGV[0]
command.bar = true if ARGV[1]
command.baz = false if ARGV[2]
command.make_dollars(1000000)
Just mix it up and make it a class suitable for testing.
# command_runner.rb
class CommandRunner
def run(args, command = Command.new)
command.foo = true if args[0]
command.bar = true if args[1]
command.baz = false if args[2]
command.make_dollars(1000000)
end
end
# my_application.rb
CommandRunner.new.run(ARGV)
Now the only thing you don't have tested is your default parameter on the run command and the one line in the file my_application.rb
Hope that helps.
Brandon
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 am creating a Rubygem that will let me generate jekyll post files. One of the reasons I am developing this project is to learn TDD. This gem is strictly functional on the command line, and it has to make a series of checks to make sure that it finds the _posts directory. This depends on two things:
Wether or not a location option was passed
Is that location option valid?
A location option was not passed
Is the posts dir in the current directory?
Is the posts dir the current working directory?
At that point, I am really having a hard time testing that part of the application. So I have two questions:
is it acceptable/okay to skip tests for small parts of the application like the one described above?
If not, how do you test file manipulation in ruby using minitest?
Some projects I've seen implement their command line tools as Command objects (for example: Rubygems and my linebreak gem). These objects are initialized with the ARGV simply have a call or execute method which then starts the whole process. This enables these projects to put their command line applications into a virtual environment. They could, for example hold the input and output stream objects in instance variables of the command object to make the application independant of using STDOUT/STDIN. And thus, making it possible to test the input/output of the command line application. In the same way I imagine, you could hold your current working directory in an instance variable to make your command line application independent of your real working directory. You could then create a temporary directory for each test and set this one as the working directory for your Command object.
And now some code:
require 'pathname'
class MyCommand
attr_accessor :input, :output, :error, :working_dir
def initialize(options = {})
#input = options[:input] ? options[:input] : STDIN
#output = options[:output] ? options[:output] : STDOUT
#error = options[:error] ? options[:error] : STDERR
#working_dir = options[:working_dir] ? Pathname.new(options[:working_dir]) : Pathname.pwd
end
# Override the puts method to use the specified output stream
def puts(output = nil)
#output.puts(output)
end
def execute(arguments = ARGV)
# Change to the given working directory
Dir.chdir(working_dir) do
# Analyze the arguments
if arguments[0] == '--readfile'
posts_dir = Pathname.new('posts')
my_file = posts_dir + 'myfile'
puts my_file.read
end
end
end
end
# Start the command without mockups if the ruby script is called directly
if __FILE__ == $PROGRAM_NAME
MyCommand.new.execute
end
Now in your test's setup and teardown methods you could do:
require 'pathname'
require 'tmpdir'
require 'stringio'
def setup
#working_dir = Pathname.new(Dir.mktmpdir('mycommand'))
#output = StringIO.new
#error = StringIO.new
#command = MyCommand.new(:working_dir => #working_dir, :output => #output, :error => #error)
end
def test_some_stuff
#command.execute(['--readfile'])
# ...
end
def teardown
#working_dir.rmtree
end
(In the example I'm using Pathname, which is a really nice object oriented file system API from Ruby's standard library and StringIO, which is useful for for mocking STDOUT as it's an IO object which streams into a simple String)
In the acutal test you could now use the #working_dir variable to test for existence or content of files:
path = #working_dir + 'posts' + 'myfile'
path.exist?
path.file?
path.directory?
path.read == "abc\n"
From my experience (and thus this is VERY subjective), I think it's ok sometimes to skip unit testing in some areas which are difficult to test. You need to find out what you get in return and the cost for testing or not. My rule of thumb is that the decision to not test a class should be very unusual (around less than 1 in 300 classes)
If what you're trying to test is very difficult, because of the dependencies with the file system, I think you could try to extract all the bits that interact with the file system.