Assert Yin Yang

AYY applies the ExecuteAroundPattern to redundant assertions before and after the Activate line of a test case.

First, replace...


        def test_activate_makes_foo_bar_positive

        assert ! foo.bar()

        activate()

        assert foo.bar()

        end

...with this:


        def assert_activate_makes_foo_bar_positive

        assert ! foo.bar()

        yield

        assert foo.bar()

        end


        def test_activate_makes_foo_bar_positive

        assert_activate_makes_foo_bar_positive do

        activate()

        end

        end

Now abstract the assertion pattern from the asserted statements. You get this:


        def test_activate_makes_foo_bar_positive

        assert_yin_yang \ 

        proc{ activate() },

        proc{ foo.bar() }

        end

assert_yin_yang calls its second proc{} twice. Before activate(), the proc expects to fail, and afterwards it expects to pass. Available in the latest version of AssertTwoPointOh:

http://assert2.rubyforge.org/assert_yin_yang.html

RSpec (http://rspec.info) uses 'lambda { ... }.should change' for this. Examples:


        lambda { @stack.push :foo }.should change(@stack, :size)

        lambda { activate() }.should change { foo.bar }.from(false).to(true)

The first example uses the change(target, method) syntax. The second uses a block which gets called twice, as in the assert_yin_yang.

the lexical irritation for me is that both the Activate block and the Assert block should be ... blocks. That's important for AssertTwoPointOh, because only wrapped blocks can be introspected.

but the "lambda" verbiage feels excessive. I fix that like this (works in RSpec too):


        def oO(&block); block; end

That could lead to...


        assert oO{ false_then_true() } do  #  oO{ } is AsciiArt for a cartoon thought balloon...

        activate()

        end


        oO{ activate }.should flip{ false_then_true() } # I made flip{} up (-;

And they lead to this:


        def yin_yang(&block); block; end


        assert yin_yang{ false_then_true() } do

        activate()

        end

Here, it uses the ExecuteAroundPattern, as an assertion, to check that 4 new Prop records get created:


        def test_find_created_props

        names = %w[hip hop dont stop]


        props = assert_latest Prop do

        create_props(names)

        end


        assert_equal names, props.map(&:name)

        end

The latest version (in AssertEfficientSql) can check an arbitrary sequence of different model types: assert_latest Prop, Accessory, Frog, etc.