[Nitro] Recent bug

[Judson Lester]

On 2/26/07, Jonathan Buch <john at oxyliquit.de> wrote:
> Hi,
>
> > And here's the patch bundle.
>
> that's great!
>
> > Is there any plan to convert tests into specs?  test2spec seems to be
> > retired from rspec...
>
> Too bad I don't have much experience with rspec.  What I like about is:
> the ability to specify human readable text as context/spec.  What I
> find a little weird:  writing '@something.should_be_empty' instead of
> 'assert @something.empty?'.  The test::unit form is less opaque (for me)
> than rspec, it 'looks and behaves' more like normal Ruby...

I got over that VERY quickly :)  And this point that I saw made
recently is particularly cogent:
@actual.should_eql @expected
 is a lot clearer in intent than
assert_equal(@actual_or_expected, @expected_or_actual)

Also, having mocks built in is so nice.  And string diffs.  Oh, (and
you might have seen this one coming, given my rampage through Og)
rspec has such a cleaner architecture than Test::Unit.  Extending
RSpec is a breeze - Test::Unit is a nightmare.

> That said, I'm ok with using rspec exclusively.  When I get the chance
> (between organizing stuff for going to finland) I will read a little
> into rspec and try to learn by rspec'ifying my tc_controller_param stuff.

Their docco is very nicely laid out.  And the whole thing is pretty
POLS.  Only con that I see to rspec at all is that their devs are a
little religious about BDD.

I still want a runner that would produce skeleton classes and methods
based on specs (and possibly even specs from mocks...) but this would
apparently be against the RSpec Way - so it remains a project for a
rainy day.

> >> tc_store.rb is failing on my box now that I've pulled the repo.  It
> >> looks like Og::Manager#store is returning nil, now?  Some of my own Og
> >> based code is broken by this pull as well.  If no one else is working
> >> on it right now, I'll continue to work on a fix.
>
> This change was done because of the store-leak problem.  Though instead
> of .with_store I'd rather had liked to use .store(&block) instead of
> .with_store(&block) and make .get_store/.put_store private (only to be
> used by .store).

I saw that exchange.  Honestly, get_store/put_store is easier to
test/spec, and more in keeping with the Ruby paradigm of close-on-done
blocks being a convenience.  After all, if I really wanted to, I could
__send(:get_store)__.  Lets not get fascist about it; this isn't Java
:)

Judson