Cucumber errors suppressed (not displayed fully) - ruby-on-rails

I just installed cucumber, and I tested it. I got the following error:
teefcomp:cucumber-intro teef$ cucumber features/manage_users.feature
Using the default profile...
F----F
Failing Scenarios:
cucumber features/manage_users.feature:6 # Scenario: User List
1 scenario (1 failed)
4 steps (4 skipped)
0m0.029s
It seems to be suppressing the error. I was expecting something like:
Feature: Manage users
In order to understand my user base better
As an administrator
I want to view a list of users
Scenario: User List
Given I have users named George, Mary
uninitialized constant User (NameError)
./features/step_definitions/user_steps.rb:3
./features/step_definitions/user_steps.rb:2:in '/^I have users named (.*)$/'
features/manage_users.feature:7:in 'Given I have users named George, Mary'
Anyone know how to get cucumber to display the errors in full?
--backtrace, --verbose, -b and --trace do not work; I still see F----F and the failing scenario is listed, but I still expect something like description on the "NameError" line. Is this a feature of an older version of cucumber? (I'm using screencasts to start using cucumber.)

running with the -b flag should give you a full backtrace
cucumber features/manage_users.feature -b
EDIT:
Additionally, you can use the full notation of --backtrace. If you are running via rake, run with the --trace flag
to get full output, you can use the --format flag. I generally use --format pretty to get a line-by-line walk through.
from the --help output.
-f, --format FORMAT How to format features (Default: pretty). Available formats:
debug : For developing formatters - prints the calls made to the listeners.
html : Generates a nice looking HTML report.
json : Prints the feature as JSON
json_pretty : Prints the feature as pretty JSON
junit : Generates a report similar to Ant+JUnit.
pdf : Generates a PDF report. You need to have the
prawn gem installed. Will pick up logo from
features/support/logo.png or
features/support/logo.jpg if present.
pretty : Prints the feature as is - in colours.
progress : Prints one character per scenario.
rerun : Prints failing files with line numbers.
stepdefs : Prints All step definitions with their locations. Same as
the usage formatter, except that steps are not printed.
tag_cloud : Prints a tag cloud of tag usage.
usage : Prints where step definitions are used.
The slowest step definitions (with duration) are
listed first. If --dry-run is used the duration
is not shown, and step definitions are sorted by
filename instead.
Use --format rerun --out features.txt to write out failing
features. You can rerun them with cucumber #rerun.txt.
FORMAT can also be the fully qualified class name of
your own custom formatter. If the class isn't loaded,
Cucumber will attempt to require a file with a relative
file name that is the underscore name of the class name.
Example: --format Foo::BarZap -> Cucumber will look for
foo/bar_zap.rb. You can place the file with this relative
path underneath your features/support directory or anywhere
on Ruby's LOAD_PATH, for example in a Ruby gem.

If your application is a Rails app, you can use the #allow-rescue tag for the scenario-of-interest, then your rails test_log will include more details about where in your application the error was originally raised.
From the command line you can quickly look at the end of the test log with tail -n200 log/test_log.rb (adjust the number of lines to see the portion of interest).

Related

Rails: How to pass data to Bash Script

I have a Rails webapp full of students with test scores. Each student has exactly one test score.
I want the following functionality:
1.) The user enters an arbitrary test score into the website and presses "enter"
2.) "Some weird magic where data is passed from Rails database to bash script"
3.) The following bash script is run:
./tool INPUT file.txt
where:
INPUT = the arbitrary test score
file.txt = a list of all student test scores in the database
4.) "More weird magic where output from the bash script is sent back up to a rails view and made displayable on the webpage"
And that's it.
I have no idea how to do the weird magic parts.
My attempt at a solution:
In the rails dbconsole, I can do this:
SELECT score FROM students;
which gives me a list of all the test scores (which satisfies the "file.txt" argument to the bash script).
But I still don't know how my bash script is supposed to gain access to that data.
Is my controller supposed to pass the data down to the bash script? Or is my model supposed to? And what's the syntax for doing so?
I know I can run a bash script from the controller like this:
system("./tool")
But, unfortunately, I still need to pass the arguments to my script, and I don't see how I can do that...
You can just use the built-in ruby tools for running shell commands:
https://ruby-doc.org/core-2.3.1/Kernel.html#method-i-60
For example, in one of my systems I need to get image orientation:
exif_orientation = `exiftool -Orientation -S "#{image_path}"`.to_s.chomp
Judging from my use of .to_s, running the command may sometimes return nil, and I don't want an error trying to chomp nil. A normal output includes the line ending which I feed to chomp.

Feature test for command line program Ruby / RSpec

I have a script that I want to run within some tests using RSpec that I want to test the input / output on.
For example,
I have a script 'script.rb' that I run using 'ruby script.rb'
The script then outputs to STDOUT and takes an input using STDIN. I want to test this using RSPec and check that everything works appropriately (a feature test). How would I go about doing this? Just do an execute 'ruby script.rb' within RSPec and then test that the output is what I expect and that it takes input from STDIN?
Since you want to test your script as a black box (only STDIN/STDOUT), you may perfectly do it via system() call: just make sure to clean up all side effects your script is leaving (for example, temporary files).
EDIT: Just create some file with needed content, say stdin.txt.
After that you may run your command this way:
system('cat stdin.txt | ruby myscript.rb')

How to include test case descriptions in lcov/genhtml code coverage output

I'm using lcov to generate code coverage reports for a C code base. I would like to integrate test descriptions into the final output (using lcov's gendesc utility.)
However, I have no clue on how to do that, and documentation on gendesc seems rather sparse (as far as the good old google has been able to tell me.)
The gendesc info at LTP describes how to create the input test case description files (as expected by genhtml). And the genhtml info provides --show-descriptions, and --description-file for inputting such test case description files.
However, I don't know how to reference the test cases so that they get included in the final report. genhtml sees them as unused test cases and thus keeps them out of the generated html output. I can use --keep-descriptions, but that doesn't tell me what test cases were run (obviously because I do not know how to make the reference from code to test description.)
So, how do we tell lcov/genhtml which tests were run in the final output? Any ideas?
To associate a test case name with coverage data, specify that name while collecting coverage data using lcov's --test-name option:
lcov --capture --directory project-dir --output-file coverage.info --test-name "test01"
Then continue with the steps that you already mentioned, that is create a test case description file "tests.txt":
test01
Some test
Convert it into the format expected by genhtml:
gendesc tests.txt --output-filename tests.desc
Finally specify the descriptions file to genhtml:
genhtml coverage.info --output-directory out --description-file tests.desc --show-details

understand line of code using rails bundler gem class methods: spec = Bundler.load_gemspec(Dir["./{,*}.gemspec"].first)

I'm trying to load a ruby on rails app called fatfreecrm (https://github.com/fatfreecrm/fat_free_crm).
Cannot run off rails development server on my machine. Code fails due to the following line:
spec = Bundler.load_gemspec(Dir["./{,*}.gemspec"].first)
(line 32 in project Gemfile: https://github.com/fatfreecrm/fat_free_crm/blob/master/Gemfile).
Trying to diagnose the problem but having trouble understanding what this does. In particular what directory does ["./{, *}.gemspec" refer to? Dont understand the {, *} shorthand.
Thanks
Evan
That's standard Unix shell glob syntax for a list of options that get expanded. I.e. in a Unix shell
foo{a, b, c}bar
will get expanded to
fooabar foobbar foocbar
So,
./{, *}.gemspec
will get expanded to
./.gemspec ./*.gemspec
In Ruby's Dir::[] those don't get expanded like in the shell, but they are treated as a pattern against which to match the filenames, similar to how a regex works.
See the documentation for Dir::[], which refers to the documentation for Dir::glob, for details.

How can I syntax check (not render) a Rails 3 ERB template file?

I'm trying to have a git pre-commit hook perform a syntax check on all Ruby code; there is one on GitHub at https://github.com/cypher/git-ruby-syntax-check.
It attempts to check .erb files by erb -x to translate them into Ruby code and then passes the output to ruby -c for syntax checking. Unfortunately, Rails 3 introduced a custom ERB parser that is incompatible with Ruby's standard ERB, and so the pre-commit hook is finding errors where there are none.
Is there some equivalent to erb -x that will output Ruby code from a Rails 3 ERB file?
I have not dug much into either of these but you might try rails-erb-check (Git project) or this blog entry. I agree with shingara but the Blog Post describes a situation where this is useful and I wonder if you are in a similar position:
Diaspora is pretty fluid right now. This means we are have some green
tests, some missing tests, and other tests that check intent (not
implementation). In an ideal world, I suppose test cases would cover
all of our bases...
Until then, I've added a new task to my fork, check_syntax:all. This
breaks down further to the subtasks check_syntax:erb,
check_syntax:haml, check_syntax:haml_ruby, check_syntax:sass, and
check_syntax:yaml.
If you get an "argument list too long error" for rails-erb-check , you can try rails-erb-lint which scans your current views folder.

Resources