A talk I gave at LRUG in 2011, about the plethora of testing frameworks in Ruby, and the urge to write my own

1. you
an
existing
library
(the horse is
probably your ego)
at some point in your career, as a programmer, you will become frustrated with your tools, with the software you use every day.
It will start as a chafe, as some mild friction, but will grow, it will fester, and nag at you, distracting you from otherwise productive endeavours.

2. you your
ideal
library

3. language ✘
app framework ✘
test framework ✔

4. test/unit
rspec
cucumber
you hate test/unit because it’s a convoluted codebase that’s a pain to work with and impossible to extend
you hate rspec because it’s bloated and you bear some inexplicable long-term grudge against it, and the latest API change is the straw that broken your
proverbial camel’s back
or maybe you hate cucumber because it’s slow and limited
for me it was test/unit

5. before / setup
test ...
should ...
it ...
after / teardown

6. blah = Hubris.new do
before do
@x = 1
end
it “works” do
raise unless 1 == @x
end
after do
@x = nil
end
end
blah.run

7. class Hubris
def initialize(&block)
instance_eval(&block)
end
def before(&block)
@before = block
end
def it(name, &block)
@test = block
end
# etc ...
def run
instance_eval(&@before)
instance_eval(&@test)
instance_eval(&@after)
end
end
stash
evaluate
evaluate

8. before / setup
test ...
should ...
it ...
after / teardown
@f = File.new
@f.unlink
@f.read
in order to share state, you either need the code in all three stages to run with the same value of self,
or copy state around like crazy

9. subcontexts:
parent & child
def run_befores
@parent.run_befores if @parent
instance_eval(&@before)
end
def run
run_befores
instance_eval(&@test)
# etc ...
end
in order to share state, you either need the code in all three stages to run with the same value of self,
or copy state around like crazy

10. Hubris.new do
def some_method
@x = 1
end
it “works” do
raise unless 1 == some_method
end
end
where does this
method live?
the value of self in the method needs to be the same as in the test
you find yourself either needing to re-implement inheritance, or change your library implementation to be based on inheritance.
This is the point at which your simple library turns a corner, and becomes non-obvious.

11. all of this has
happened before;
and it will all
happen again.
how do I know all this? I have just done it.
step through the history of the kintama project.
as it started to get more complicated, i wondered if anyone else had done the same.

12. at least 45 libraries
pure testing - not testing ‘addons’ like mocha
i became profoundly depressed.

13. AXIS OF
WTF
either building the same features on TOP of Test::Unit
or a complete standalone implementation of a nested test framework

14. it’s probably OK.
it’s a good learning experience
you will learn loads about advanced block manipulation and a new appreciation for
convergent evolution - independent appearance of features which tend towards similarity
diversity is a good thing

15. except maybe it’s
not OK?
why do we feel the need to re-invent?
Is it because the existing libaries are “too heavy”, and you think people need something “lightweight”? Perhaps you think it’s time for a “testing library for
the rest of us”?
I think “too heavy” and “for the rest of us” can be “developer smells” - I suspect it means that either the project is ideologically incompatible with their
particular manifesto, or that they cannot be bother putting the effort in to understanding the existing code.
I’m not sure I really buy my “convergent evolution” explanation, because while there might be some form of “survival of the fittest” that weeds out the
weaker libraries, we are not developing blindly.
We are aware of these other islands of development, or certainly can be, but instead choose to go ahead and repeat the same decisions.

16. maybe don’t write
anything.
perhaps there’s already another trailblazing re-implementer who has satisfied your need.
use that!
question the urge to create another project just to bump up your authority on working with rails

17. maybe become a
contributer.
maybe there is something you can do to modify one of the existing projects to address your needs? (do you even really understand your needs?)
this is the point of open source that is most often missed; we can collaborate.

18. open source
responsibility.
github makes it very easy to make a project available for other people to use
but it also doesn’t provide any differentiation between your polished, maintained, and thoroughly tested and the piece of shit that I knocked up because I
am bored and arrogant.
if you know something is broken, at least update the README.
if you fork something, send a pull request or communicate in some other way WHY you have forked. (see cucumber bundle)
if you get a pull request, deal with it! look after your code and the people who use it.

19. give some context.
if you’re going to write a replacement tool, make it clear in the README that you understand its setting within the larger ecosystem.
this is like a literature review in a dissertation; it demonstrates that you are aware of other tools, how they work, what their problems are.

20. kill-ish your darlings.
bit.ly/rubytesting
have the courage to say “this is just a sketch, and I’m not suggesting that it is suitable for public consumption”.