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

---

See also assert_latest: http://www.oreillynet.com/onlamp/blog/2007/07/assert_latest_and_greatest.html

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.