Support for rspec etc

[Dr Nic]

Currently the two generators (app_generators/rbiphonetest and
rbiphonetest_generators/model) assume you'll use test/unit. That
because that's what I use and I was just trying to get the project
working at all :)

The project "needs" to support alternate test frameworks. A user
should only have to indicate their test framework preference once,
when they run the "rbiphonetest" command.

Say:

rbiphonetest . -T rspec

The "script/generate model" generator should then generate rspec
stubs, etc.

The solution, first invented for the merb project, is to break the two
generators above into "code" and "test" generators. One "test"
generator for each test framework: test/unit, rspec, etc.

When I break up the current generator, I'll report back to this thread
and rspec, test/spec people can see the design pattern to support for
their framework.

Use google group's "notify me of updates to this thread" option if you
want to track the progress.

Cheers
Nic

[Aaron VonderHaar]

I made a draft/exploratory version of two new rbiphonetest generators:
rspec_model and story. My code's at http://github.com/avh4/rbiphonetest/commits/master

As you hinted, we still need to clearly define the line between the
app generator and the component generators. I think this is important
because using test/unit and rspec and rspec/story are not mutually
exclusive-- someone might want to use more than one at the same time.
So I think rbiphonetest shouldn't require a choice up front if at all
possible-- maybe it just sets a default for which type of test
"generate model" generates-- but I think it should be possible to
generate new tests, specs and stories at any point regardless of what
configuration was chosen initially. The biggest hurdle I see in doing
that at this point is that the Rakefile will need to be broken up so
that, for instance, "generate spec" can add the Spec::Rake::SpecTask
task if it hasn't already been created.

The rspec/story support will also take a bit more thought since a new
story doesn't necessarily correspond to an individual model class.
I'll start to get a better idea of how to do this when I write a few
tests for my cocoa app.

When I get a chance to work on this some more, I'll take a look at how
the merb folks have done it.

Cheers,
--Aaron V.

[Aaron VonderHaar]

FYI, my latest commit has the generated Rakefile broken up so that
"generate test_unit" and "generate spec" can add their rake tasks as
needed, rather than creating all the rake tasks up front.

http://github.com/avh4/rbiphonetest/commits/a9aab9af1257af4291434198870ab2b9452b8adc


Also, I wrote some specs and stories for one of my cocoa apps, and I
am quite happy with the results! For anyone who wants to see them as
an example:

http://github.com/avh4/time-tracker-for-mac/tree/master/stories
http://github.com/avh4/time-tracker-for-mac/tree/master/spec

An interesting thing to note is the trick I had to use to allow
mocking an objc method that returns a primitive data type. (The mock
object must inherit from OSX::NSObject so that we can tell RubyCocoa
which data type to use.)

http://github.com/avh4/time-tracker-for-mac/tree/master/spec/t_project_spec.rb

--Aaron V.

On Jul 4, 8:37 pm, Aaron VonderHaar <gruen0aer...@gmail.com> wrote:
> I made a draft/exploratory version of two new rbiphonetest generators:

> rspec_model and story. My code's athttp://github.com/avh4/rbiphonetest/commits/master

[Nic Williams]

As you hinted, we still need to clearly define the line between the
app generator and the component generators.  I think this is important
because using test/unit and rspec and rspec/story are not mutually
exclusive-- someone might want to use more than one at the same time.

In newgem there an "install_test_unit" and "install_rspec" generator that creates the .rake, _helper.rb files to support the specific test framework. By default, one of them is run with the newgem command, but the other can be run later. 

I'll take your branch, and have a look at going down this path of having install_* generators and then simplified model generators. I'll do it in a branch of my own. We'll see how it goes.

--
Dr Nic Williams
* Learn TextMate for Rails2 - http://peepcode.com/products/textmate-for-rails-2 *
Training in Ruby/Rails/JavaScript - http://drnicacademy.com
Fun with Ruby/Rails/Javascript - http://drnicwilliams.com
Photos of our new daughter & family- http://flickr.com/photos/drnic

[Nic Williams]

Ok, I've taken your great work and started a branch "multi_test" in my repo, which evolves it.

http://github.com/drnic/rbiphonetest/commit/07008f1261852d267df2ee178812430bc0e56ae5

Now, you can specify an initial test framework (rspec or test_unit (default)) and it creates the spec or test folder, plus the helper file, plus the rake task file.

Later you can install the other test framework, via a generator: install_rspec and install_test_unit.

The "rspec_model" generator has been removed. The "model" generator determines what test frameworks you have installed and generates test files for them all. Then you'd keep or delete what ever files you don't want.

I'd prefer a question+answer prompt to ask the user which test framework to generate the tests for, but really, I don't think there'll be many developers who are using tests + specs simultaneously. But it does support them by creating test files for both.

In summary:

script/generate model FooBar

creates either spec/foo_bar_spec.rb or test/test_foo_bar.rb depending whether your project has a spec or test folder, or both.

Thoughts? Perhaps pull my multi_test branch into a new branch of your own, build the gem and test it out. 

Nic