Muack -- Yet Another Mocking Library.
I spent some time implementing an RR clone last few days,
and now I "guess" it already has most of the features in RR.
Though I am quite tired of doing some sort of promotion,
but I still somehow feel responsible to let people know
what I'd done, especially when I am quite proud of it.
wc lib/**/*.rb on both Muack and RR:
Muack 0.7.0: 452, 1118, 11824
RR 1.1.1: 3823, 8564, 113447
Of course this doesn't really say anything as RR would
definitely has more features than Muack and I don't really
write documents in the source code, but still I believe
Muack should be much simpler than RR speaking to internal
structures. Or at least it's much easier to understand to me.
I never really understand how RR works even though I'd read
the source many times when I was trying to debug RR.
The interesting thing is, actually I started this project
2 years ago. The first commit was at: Sun Aug 14 03:35:39 2011 +0800
However I stopped developing it when I realized that RR is
doing things much more complex than I thought. It might be
quite hard to do the same thing without a lot of efforts.
(time efforts, basically) Since I lost the very reason
to implement it --it's not simple at all--, I stopped.
I picked it again at: Fri Jun 21 20:13:32 2013 +0800
Roughly 1 week ago. The reason for now is different.
Aside from some personal reasons (like I am tired of
current work, and most of what I've done is already
done), the reason for picking this up again was RR 1.1.0.
In RR 1.1.0, they introduced a autohook mechanism to
find out which testing framework you're using, and insert
API and setup/teardown methods into it. The idea is fine,
but the implementation troubles me so much...
The reason is that there are simply too many versions for
test/unit and minitest! Ruby has built-in test/unit, which
might be built on top of minitest, depending on Ruby versions.
Ruby itself also bundles minitest into core (so that they
could build test/unit on top of it). We might have minitest
installed, and specified in Gemfile.
Gees, I don't know why, but sticking with core API should be
always fine, like using setup/teardown and include. They are
not going to be changed across versions. But people just want
to do more things, more integrations, and things got very,
very complicated if we're trying to make those automatic.
Now we also have activesupport which also has its extensions
to... either unit/test or minitest! And we all know that there
are a number of versions of activesupport... Think about combinations!
I couldn't find a good way to make RR 1.1.0 work in our Rails
application, which works perfectly fine with either built-in
test/unit or minitest. Use
include RR::Adapter::RRMethods would
also print a deprecation warning, though it does fix the issue.
Lastly I found that just
require 'rr/without_autohook' does the best.
However occasionally it still has some issues. Like...
It Works On My Computer ™
Yeah, but it doesn't work on Travis. I have no idea why.
Moving to Muack solves all the hassle above, of course,
since I would never try to do something like this in core
library. They could build rr-minitest, rr-unittest, rr-rspec,
rr-activesupport, and so on so forth.
Ironically that actually there's no problems at all for
RR working in my other libraries. Because I always use Bacon
and there's no such adapter for it, I could always do it
the most straightforward way to make it integrate perfectly.
However I still have to work with Rails -- I need food.
Of course I could also blame Rails for this, and indeed
I did, because now there's yet another issue when I tried
to upgrade to Rails 4. Apparently things are different again.
My old good codes which integrate standalone test/unit and
minitest no longer works with Rails application tests.
The thing is -- somehow only in
rake test, but not loading
Rails testing environment itself. They must have done something
rake testrather than in the testing environment.
And this also reminded me that running
loads the application 4 times -- one for
and the others for
rake test:integration. Yeah I know this is so easy
to implement that way, but this is really introducing a ton of issues.
The most obvious one is -- it's sooooo much slow.
I don't know if Rails 4 has solved this issue or not.
Hopefully the answer is yes. Anyway, the point is --
People just do random things to integrate everything,
and since there's simply too much stuffs, it's too
complicated and things would just go wrong. I have no
objection if all of these could be done right,
but I just don't see it... :(
Oh sorry for so much complains. Just couldn't resist.
What I really want to say is -- RR involved into above
and introducing yet another complexity, making the
chaos even more chaotic, after 1.1.0 release.
I could try to fix it in RR, but that goes back to the
original problem -- it's too complex and I don't know
what's really going on thus I don't know where to fix.
And now I feel I could write my own version to replace
RR, which might be faster (I did it on last weekend,
only 2 days), and reduce the pain in the future all together.
That's where I am at.
Bacon is the only library I don't see why I should write my own.
As for Rails, it's simply too large for a one-man rewrite,
otherwise it must be the first one I want to rewrite totally.
See Muack's README for more detail. Blog's for thoughts :P