Announcing Ruby Fix 0.7!
With 148 lines of simple code built on top of Spectus expectation library, facilities such as benchmarking and mocking are not supported. Fix offers however a consistent syntax to focus your BDD.
While specs behave like documents which can be logic-less, their interpretation should not be questioned regardless of the version of Fix, preventing from software erosion. Also, Fix specs are compliant with RFC 2119, to qualify requirements.
Monkey-patching, magic tricks and friends are not included. Instead, animated by authentic and unmuted Ruby objects, unambiguous, understandable and structured specs are encouraged.
Why Fix instead of RSpec?
Let me start with a confession. Despite 10 years of Ruby, I still do not understand anything about the source code of RSpec.
This is alarming when one considers that if the programming complexity of the testing tool on which we pin our expectations is greater than the complexity of the program to be tested, tests are less significant.
However the current implementation of this tool is probably more complex than most programs to be tested with. And when I do anyway against a piece of code, I feel like using a sledgehammer to crack a nut. Worst, I can not help doubting the results RSpec provides.
Here is why, with a basic example:
And now, let’s look at the result:
You got it, according to RSpec, App.new is 42.
While this one could be fixed quickly, by reversing actual and expected values, such bugs alert us against the possible impact on the final application.
Writing A Spec With Fix
Given this duck class:
When we write this spec:
Then we should see:
For 1.0.0 there are no major changes planned. Please, tell us what you think. Like. Dislike. We would like to hear it all.
Thanks for reading and happy hacking!