RSpec-1.1.3 and ZenTest-3.9.1 6
ZenTest’s last two releases are not compatible with previous versions of RSpec. This is good news because Autotest now exposes better extension points for subclasses like those that ship with RSpec. Before, RSpec had to monkey patch Autotest to control the mappings of specs to files to run, and the list of files/directories to ignore. Now RSpec gets to use public methods (instead of instance variables) and documented hooks to do it’s work.
In the long run, this will keep things more flexible for both RSpec and ZenTest. In the short run, the catch for you is that you have to use compatible versions of RSpec and ZenTest. They are:
| RSpec version | ZenTest version |
|---|---|
| <= 1.1.1 | <= 3.7.x |
| 1.1.2 | 3.8.x |
| 1.1.3 | 3.9.x |
Wouldn’t it be nice for RSpec to ship with a compatible version of ZenTest? Seeing as every recent update of Rspec required an update of ZenTest, and that wasn’t always immediately obvious, that seems like a user-friendly way to go.
Actually it’s the other way around. The last two releases of ZenTest broke RSpec, so we released so you could upgrade to ZenTest right away. Nobody was twisting your arm saying you had to, but at least you had the option. Seems a pretty user-friendly way to go to me.
I really appreciate your reaction time and rspec’s frequent releases, make no mistake. Let me just describe my experience: To build the recent rspec trunk, an upgrade to the newest ZenTest version (2.9.x) was necessary, which in turn made the default autotest-binary not play nice with rails-apps that had a vendor’d copy of rspec, so they all had to be updated to the newest rspec(_on_rails) release. Just seemed like a lot of hoops to go through (twice already) for essentially no gain.
Let’s say Rspec included its own bundled version of autotest (the only part of ZenTest used, right?), then there would be no need to do intermediate releases (and publicise them) when ZenTest changes.
And lets say that bundled version is called autospec, then that would enable projects with both ./test and ./spec directories to run both in parallel. And, you could run vendor/rspec/bin/autospec if you followed the Rspec documentation’s recommendation and vendor’d in the Rspec gem. That would help projects with multiple developers using autotest a lot, I think.
Stupid idea? Unnecessary?
Not a stupid idea, but generally unnecessary. As I pointed out, one reason these last releases of ZenTest were good was that they allowed subs like RSpec’s to extend without monkey patching – so the likelihood is that we won’t be in this position again.
I think no matter in what version it is. Maybe, which one will gives best to the user and where they feel comfortable. They will go with it!!!
In the end, it all depends on the user. I am more comfortable with the latter version. Just stick to it I guess. And upgrades are good because they make things more flexible.