Question

Today I am going to get as far as I can setting up my testing environment and workflow. I’m looking for practical advice on how to setup the test environment from you guys who are very passionate and versed in Ruby Testing.

By the end of the day (6am PST?) I would like to be able to:

1. Type one 1-command to run test suites for ANY project I find on Github.
2. Run autotest for ANY Github project so I can fork and make TESTABLE contributions.
3. Build gems from the ground up with Autotest and Shoulda.

For one reason or another, I hardly ever run tests for projects I clone from Github. The major reason is because unless they’re using RSpec and have a Rake task to run the tests, I don’t see the common pattern behind it all.

I have built 3 or 4 gems writing tests with RSpec, and while I find the DSL fun, it’s less than ideal because it just adds another layer/language of methods I have to learn and remember. So I’m going with Shoulda. But this isn’t a question about which testing framework to choose.

So the questions are:

1. What is your, the SO reader and Github project committer, test environment setup using autotest so that whenever you git clone a gem, you can run the tests and autotest-develop them if desired?
2. What are the guys who are writing the Paperclip Tests and Authlogic Tests doing? What is their setup?

Thanks for the insight. There are tons of resources describing how to use the different testing frameworks, but almost nothing on the actual setup and workflow. Looking for answers that will make me a more effective tester.

Answer 1

The most common convention probably is rake test, rake spec, or maybe even just rake.

Of course, there is no question that this will fail with many projects, in particular the ones without tests or specs.

It might be possible to parse the output of rake -T if a Rakefile is there, and act on that, but there really is no way you will cover ALL projects on GitHub.