Searching for common ground
Now that I have downloaded and built the source for Ioke E, I wanted to start using it. After all, I made a goal back in January to start using it, but as of yet had failed to follow through with it. Oh sure, I’ve been keeping up with the blog posts and looking at it from time to time, but really hadn’t made any steps to speak of. Until today.
I think that what I really needed was to find some common ground with Ioke. Something I could call familiar and the branch out from. ISpec is where I found it. I found it in two ways really, first in the ability to write specs to test my knowledge of Ioke coding and also in reading existing specs that have been written. These specs run when you download and build Ioke from source, which incidentally, is a painless process I would recommend to any interested.
So what’s next?
Note:I’ve pushed my code out to github tagged as start_ispec
I started out by creating a directory for my project with subdirectories for src and test
~/working $ mkdir ioke-examples ~/working $ cd ioke-examples ~/working/ioke-examples $ mkdir src test
Next I created my first spec as test/bag_spec.ik.
use("ispec")
use("src/bag")
describe("Bag",
it("should have the correct kind",
Bag kind should == "Bag"
)
it("should return the values in assigned cells",
Bag name = "cheeze"
Bag name should == "cheeze"
)
)There is nothing really interesting being tested here, the behavior is that of pretty much any Ioke object. The only thing of note is that the use directive is from the root of the project so to specify bag.ik which as a relative path from the spec would be ../src/bag.ik, was actually just src/bag.ik. Next I made an implementation src/bag.ik as
Bag = Origin mimic
This passed. Next I started making a another spec and class. Thinking that I would keep going with this path of thought. I made test/evaluator_spec.ik as:
use("ispec")
use("src/evaluator")
describe("Evaluator",
it("should have the correct kind",
Evaluator kind should == "Evaluator"
)
describe("Evaluation",
it("should evaluate nil as nil"
Evaluator evaluate nil should == nil
)
)
)and src/evaluator.ik as
Evaluator = Origin mimic Evaluator evaluate = method ( )
This results in the following
~/working/ioke-examples$ ispec test .P.. Pending: Evaluator Evaluation true (Not Yet Implemented) Finished in 0.26 seconds 4 examples, 0 failures, 1 pending
Pretty neat that it sees it as a pending implementation. Overall this was a great success, ISpec was working, but something was still nagging me.
Something isn’t right
Maybe it’s my Ruby roots, maybe it’s that I was being picky but having to specify the source directory when referencing bag.ik and evaluator.ik just didn’t seem right. I needed something like test_helper.rb in Ruby.
I looked around for a while and finally started digging into the test directory for Ioke, which is a great reference for the language. Three cheers for TDD! After a little fiddling I found that I could make a file called test/helper.ik as follows:
use("ispec")
System loadPath << "src"This automatically loads ISpec and also adds the src directory to System loadPath, which is a list of the locations that Ioke will look for files in the use directive.
This allowed me to change use directives at the beginning of my specs to something like:
use("test/helper")
use("bag")
describe("Bag", ....Comfort level
Now that I have my ISpec basics up and running, I hope to be playing more with this interesting language. Hopefully you will be seeing more Ioke posts here soon.
Tags: getting started, ispec
Hey Jamal,
great to see you start playing with Ioke, it’s such fun isn’t it!
I just thought I’d point out a couple of things with your code above which might clear matters up a little. I’d like to focus on the following snippet:
it(“should evaluate nil as nil”
Evaluator evaluate nil should == nil
)
Ok, the first reason you’re getting a Pending (Not Yet Implemented) error is because you’re missing a comma after the description of the it. This is actually one of the most annoying pitfalls of Ioke. If you insert the comma you’ll straight away discover the second issue because in the current form this test will pass!
Obviously as Evaluator#evaluate doesn’t yet have a proper implementation, you might expect that the test shouldn’t pass. In fact, what we should be seeing is DefaultMethod’s arity checker kicking in with the following condition: Condition Error Invocation TooManyArguments.
This then leads me on to the next pitfall – method argument parameters are not optional in Ioke. This is important as the Ioke parser has no other way of differentiating messages from message arguments due to the very simple homoiconic syntax.
OK, so taking both into account, if you rewrite the above snippet as follows then you should get the expected failure and all is good in the Ioke world
it(“should evaluate nil as nil”,
Evaluator evaluate(nil) should == nil
)
Looking forward to reading more Ioke-related posts! Keep up the excellent work…