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.