I use OpenRefine fairly often and I find it great when I need to normalise (millions of rows of) raw data. But it's not a data analysis tool and you'll inevitably need another tool to create charts for example.
I think the point is something like "don't unit test the system as a whole". Black box testing is great and most definitely should be used, but should be kept very high level and unit tests should be kept very small and granular.
Lastly, I really wish the author would give suggestions for what he considers to be a better approach to testing, beyond "integration testing sucks and is a scam".
This claim is incorrect: Aman Gupta did not create RubyPython, nor does he claim to (and Aman's repo linked above even shows that his repo is a fork of my repo).
Aman has provided some comments, discussion, and code back to RubyPython over the last few days. I know this because I've been chatting with him and pulling his modifications back into the main GitHub repo[1] (which happens to be mine) and pushing them back into the canonical repo on Bitbucket[2] (which is the original creator's repo).
RubyPython was created in 2008 by Zach Raines, rewritten to use FFI in late 2010. Steeve Morin forked it as Rupy (apparently with Zach's blessing as Zach pointed me to it when I posted a bug fix to Zach's code) earlier this year. I got involved shortly after Steeve's fork. After some discussion, we (Steeve, Zach, and I) unforked Rupy back into RubyPython and opened the project a bit wider. I'm currently working on a new release (0.5) that should be out later this week that unifies the two repositories and includes some fixes and enhancements by Aman.
We're using Schacon's wonderful hg-git[3] for navigating between git and hg.
You might be interested in contest[1], which adds a thin layer of sugar over Test::Unit.
In addition to nested contexts, it also lets you provide your test name as a string rather than a method name, to avoid wearing out your underscore key with "def test_new_instance_should_respond_to_foo".
