Encountering: syntax error, unexpected tIDENTIFIER, expecting keyword_end - ruby

I'm creating a directed_graph class in Ruby to practice using RSpec. I keep getting the above error (at line 13, which is the line below with "eql(0)" on it).
I don't really understand the error, especially since this RSpec code looks very similar to other RSpec code I've written for other projects that works.
require "directed_graph"
include directed_graph
describe directed_graph do
describe ".vertices" do
context "given an empty graph" do
it "returns an empty hash" do
g = directed_graph.new()
expect(g.vertices().length()).to() eql(0)
end
end
end
end
EDIT: I believe the problem was (1) directed_graph was a class, and classes must start with uppercase letters (so I renamed is DirectedGraph), and (2) you're not supposed to write "include" for classes.
I fixed those two, and my code seems to be runnign fine for now. I'm going to leave this up here in case I missed something big.


I believe the code should look like this:
require "directed_graph"
include DirectedGraph
describe DirectedGraph do
describe ".vertices" do
context "given an empty graph" do
it "returns an empty hash" do
expect(directed_graph.new.vertices.length).to eql(0)
end
end
end
end
Let me explain why. First include usually includes Classes/Modules. Classes and modules in ruby are denoted with Capital Letters for each part of their name (also know as UpperCamelCase). When you describe a class in in rspec, you should also use UpperCamelCase. I also cleaned up the code a little bit to make it easier to read. You don't always need the () to denote a function. It is implied. But sometimes you do need it, for example with the expect function.

Related

Provide alias for Ruby's built-in keyword

For example, I want to make Object#rescue another name so I can use in my code like:
def dangerous
something_dangerous!
dont_worry # instead of rescue here
false
end
I tried
class ::Object
alias :dont_worry :rescue
end
But cannot find the rescue method on Object:
`<class:Object>': undefined method `rescue' for class `Object' (NameError)
Another example is I would like to have when in the language to replace:
if cond
# eval when cond is truthy
end
to
when cond
# eval when cond is truthy
end
Is it possible to give a Ruby keyword alias done in Ruby?
Or I need to hack on Ruby C source code?
Thanks!

This is not possible without some deep changes to the Ruby language itself. The things you describe are not methods but keywords of the language, i.e. the actual core of what is Ruby. As such, these things are not user-changeable at all.
If you still want to change the names of the keywords, you would at least have to adapt the language parser. If you don't change semantics at all, this might do it as is. But if you want to change what these keywords represent, things get messy really quick.
Also note that Ruby in itself is sometimes quite ambiguous (e.g. with regards to parenthesis, dots, spacing) and goes to great length to resolve this in a mostly consistent way. If you change keywords, you would have to ensure that things won't get any more ambiguous. This could e.g. happen with your change of if to when. when is used as a keywords is case statements already and would thus could be a source of ambiguity when used as an if.

yard-rspec-plugin and support for modules

I am trying to get the yard-rpec-plugin to work.
For the given example it works, but when I add a module (as my code has), it does not give the rspec info in the doc.
To give an example, the following does not work, but leave out the 'Module Test' and it works.
module Test
class String
# Pig latin of a String
def pig_latin
self[1..-1] + self[0] + "ay"
end
end
end
While going through the code I noticed that in the RSpecItHandler, the following returns a Proxy when using modules. It seems part of the problem.
obj = P(owner[:spec])
Apparently the owner (the describe handler) is not yet in the namespace?
PS. The documentation for yard is actually quite good (and I read it), but I cannot find information about this specific part.
If feel sympathy for Thermatix's question, but it is closed as unclear (Yardoc Handlers). Therefore I ask this more specific question.

I went through the code base and found that the following works
Instead of
P(owner[:spec])
Use
P(namespace, owner[:spec])
That takes care of the name-spacing of modules...

Rubocop RSpec Describes are failing

Actually i'm trying to fix that issues:
Do not use multiple top level describes - try to nest them.
The first argument to describe should be the class or module being tested.
I have eight tests in that format:
describe 'PublicanCreatorsCreate.init_docu_work' do
it 'accesses a directory and creates there an initial documentation' do
PublicanCreatorsCreate.init_docu_work(title, type, language, brand, db5)
Dir.exist?(title)
:should == true
end
end
But what is false? The first argument contains the tested class and method.

Normally such a describe would be written as:
describe PublicanCreatorsCreate, '.init_docu_work' do
or
describe PublicanCreatorsCreate do
describe '.init_docu_work' do
It sounds like rubocop-rspec is expecting the second form.

Using RSpec, are constants within describes a big no-no?

I just spent ages trying to figure out why my specs were passing in isolation, but when running the controller and lib tests together, some specs were mysteriously failing. The culprit was this:
In one spec:
describe SomeThing do
CONSTANT_VALUE = "a value"
# ... examples etc ...
end
And in another:
describe AnotherThing do
CONSTANT_VALUE = "a different value"
# ... the rest is history
end
The values I'd assigned to these constants was leaking between my specs and causing unexpected behaviour. Am I supposed to use a let block for defining constants etc? Or something else?

Yes, let is the answer here.

Ruby Koan: test_nil_is_an_object

I have recently tried sharpening my rails skills with this tool:
http://github.com/edgecase/ruby_koans
but I am having trouble passing some tests. Also I am not sure if I'm doing some things correctly since the objective is just to pass the test, there are a lot of ways in passing it and I may be doing something that isn't up to standards.
Is there a way to confirm if I'm doing things right?
a specific example:
in about_nil,
def test_nil_is_an_object
assert_equal __, nil.is_a?(Object), "Unlike NULL in other languages"
end
so is it telling me to check if that second clause is equal to an object(so i can say nil is an object) or just put assert_equal true, nil.is_a?(Object) because the statement is true?
and the next test:
def test_you_dont_get_null_pointer_errors_when_calling_methods_on_nil
# What happens when you call a method that doesn't exist. The
# following begin/rescue/end code block captures the exception and
# make some assertions about it.
begin
nil.some_method_nil_doesnt_know_about
rescue Exception => ex
# What exception has been caught?
assert_equal __, ex.class
# What message was attached to the exception?
# (HINT: replace __ with part of the error message.)
assert_match(/__/, ex.message)
end
end
Im guessing I should put a "No method error" string in the assert_match, but what about the assert_equal?

assert_equal true, nil.is_a?(Object) is indeed the correct solution. The question is "Are nils in Ruby objects or not?", and in Ruby's case, they are. Thus, in order to pass the assertion, you should assert the truth of that test.
In the second example, when you call an undefined method on nil, you get NoMethodError: undefined method 'foo' for nil:NilClass. Thus, the exception class is NoMethodError, and the message is undefined method 'foo' for nil:NilClass. Test the failing behavior in a console, and see what you get from it, and then apply that knowledge to the test.

Are you running
ruby path_to_enlightenment.rb
at the command prompt after you correct each test? It will give you lots of help.
Also "remember that silence is sometimes the best answer" -- if you are stumped don't put in anything and the tool will help you.

Well, in holding with the typical TDD motto of Red-Green-Refactor, you should run the test (probably with rake in a separate console) and see the failure happen. From there, they have provided you a few pieces of information about what was expected.
As for style, the koans aren't really teaching that. You should just find and read some code written in ruby to get a feel for the typical conventions and idioms of the ruby community.

Simplicity is the key with Ruby Koans - when I started it I thought it must be harder than what it is, but it's not! Just ask IRB the question Koans is asking you, and after a few you get a feel for it. I've written a blog piece about it to help others, too:
Ruby Koans Answers

I remember when I did this that I tried to out think the test and tried to put in
<Answer> and <"Answer">
The thing to remember is that the actual class doesn't have to be in a string or something.
So the answer is NOT
ex.class, ex.class
As suggested above, put the code into irb and execute it.
(1..5).class == Range
is a big hint

Resources