ae 1.8.1 → 1.8.2

data/qed/04_subjunctive.rdoc

@@ -1,100 +0,0 @@
-= Subjunctives
-
-Okay. I can hear the BDDers rumbling, "where's the *should?*"
-AE has nothing against "should", but there are different
-approaches for utilizing should nomenclature in specifications,
-and AE wants to be open to these techniques. One of which
-is how Shoulda (http://shoulda.rubyforge.org) utilizes
-+should+ in a way analogous to RSpec's use of +it+.
-
-Even so, AE provides an optional mixin called +Subjunctive+ which
-can be used to create assertor methods with English subjunctive
-terms, such as +should+, or +must+, +shall+ and +will+.
-To load this library use:
-
-  require 'ae/subjunctive'
-
-Then all that is required it to define a subjunctive method for all
-objects. For example:
-
-  def will(*args, &block)
-    Assertor.new(self, :backtrace=>caller).be(*args,&block)
-  end
-
-It's that easy. Because of their commonality AE provides two such terms,
-+should+ and +must+ as optional add-ons out-of-the-box.
-
-  require 'ae/should'
-  require 'ae/must'
-
-We will use these two methods interchangeable for the rest of this
-demonstration, but to be clear they both work exactly the same way,
-and almost exactly like +assert+.
-
-Keep in mind, AE "conical" functionality does not entail the subjunctive
-forms. These are simply options you can load via your <tt>test_helper.rb</tt>,
-or similar script, if you prefer these nomenclatures.
-
-
-== Fluent Notation and Antonyms
-
-Like +assert+, +should+ and +must+ can be used as higher order functions.
-
-  4.should == 4
-  4.must   == 4
-
-Antonyms provided for +should+ as <tt>should!</tt> (read "should not") and +shouldnt+.
-For +must+ +must+, they are <tt>must!</tt> and +wont+.
-
-  4.should!  == 5
-  4.shouldnt == 5
-
-  4.must! == 5
-  4.wont  == 5
-
-
-== To Be
-
-On occasions where the English readability of a specification is hindered,
-+be+ can be used.
-
-  StandardError.must.be.raised? do
-    unknown_method
-  end
-
-The +be+ method is the same as +assert+ with the single exception
-that it will compare a lone argument to the receiver using +equate?+,
-unlike +assert+ which simply checks to see that the argument evaluates
-as true.
-
-  10.should.be 10
-  10.should.be 10.0
-  10.should.be Numeric
-
-  Assertion.assert.raised? do
-    10.should.be "40"
-  end
-
-
-== Indefinite Articles
-
-Additional English forms are +a+ and +an+, equivalent to +be+ except
-that they use <tt>case?</tt> (same as <tt>#===</tt>) instead of
-<tt>equate?</tt> when acting on a single argument.
-
-  "hi".must.be.a String
-
-  Assertion.assert.raised? do
-    /x/.must.be.a /x/
-  end
-
-Otherwise they are interchangeable.
-
-  "hi".must.be.an.instance_of?(String)
-
-The indefinite articles work well when a noun follows as an arguments.
-
-  palindrome = lambda{ |x| x == x.reverse }
-
-  "abracarba".must.be.a palindrome
-

data/qed/05_expect.rdoc

@@ -1,104 +0,0 @@
-= Expect Method
-
-Expect is another assertion nomenclature available for use in your
-tests or specifications. Inspired by Jay Fields' Expectations library,
-it provides convenient syntax for creating exception and case equality
-assertions.
-
-  require 'ae/expect'
-
-
-== Underlying Comparison
-
-Expect uses #=== for comparison. So providing an argument and a block to
-#expect we can test for a somewhat broader range of compassion than #assert.
-For example we can test for a subclass.
-
-  expect Numeric do
-    3
-  end
-
-  Assertion.assert.raised? do
-    expect Numeric do
-      "3"
-    end
-  end
-
-
-== Exception Expectation
-
-If the comparator is an Exception class or a instance of an Exception class,
-then #expect will check to see if the block raises that kind of exception.
-
-  expect StandardError do
-    some_undefined_method
-  end
-
-  expect Assertion do
-    expect(nil)
-  end
-
-This is an important distinction to note because it means #expect can not be used
-if verify instances of Exception classes.
-
-  Assertion.assert.raised? do
-    expect Exception do
-      Exception.new
-    end
-  end
-
-
-== Regex Expectations
-
-That #expect entails #=== also means we can check for Regexp matches.
-
-  expect /x/ do
-    "oooxooo"
-  end
-
-
-== Expected Method
-
-We can use #expected to make the receiver the object of expectation.
-
-  x = "dummy"
-
-  /x/.expected do
-    "x"
-  end
-
-
-== Without Block
-
-Without a block, the receiver is compared to the argument.
-
-  x.expect String
-
-
-== Negative Forms
-
-Like #assert, #expect has a negated form called #expect!
-
-  expect! /x/ do
-    "o"
-  end
-
-The pure word form for those who do not like the clever use of the
-explimation mark is #forbid.
-
-  forbid /x/ do
-    "o"
-  end
-
-
-== Functor, or Higher Order Function
-
-Like #assert, #expect can be used used as a *fluid* notation.
-
-  10.expect == 10
-
-In which case it works just like #assert, including negative forms.
-
-  10.expect! == 11
-  10.forbid  == 11
-

data/qed/06_counts.rdoc

@@ -1,33 +0,0 @@
-= Assertion Counts
-
-AE tracks the number of assertions made and the number that failed to pass.
-We can reset the count using the +recount+ class method.
-
-  old_counts = AE::Assertor.recount
-
-For example if we have one assertion pass and another fail.
-
-  assert(true)
-
-  expect Assertion do
-    assert(false)
-  end
-
-We will see that AE counted three assertions and one failure.
-
-  counts = AE::Assertor.counts.dup
-
-  counts[:total].assert == 3
-  counts[:pass].assert  == 2
-  counts[:fail].assert  == 1
-
-The #expect call is an assertion too, which is why the total count is 3
-rather than 2.
-
-Now that we are done checking counts we will restore them so that
-any other demos being run with this will tally correctly.
-
-  AE::Assertor.recount(old_counts)
-  AE::Assertor.counts[:total] += 3
-  AE::Assertor.counts[:pass]  += 3
-

data/qed/07_matchers.rdoc

@@ -1,34 +0,0 @@
-= Matchers
-
-Matchers are simply Procs or objects with the proper interface that can be
-passed to #assert or #refute (or other Assertor) as an ecapsulated test.
-
-== Proc or #to_proc
-
-Passing a Proc object or an object that responds to :to_proc, will use it
-as if it were a block of the method. This allows for a simple way to quickly
-create reusable assertions.
-
-  palindrome = lambda{ |word| word == word.reverse }
-
-  "abracarba".assert palindrome
-
-== #matches?
-
-Additionally if an object responds to #matches? then the receiver
-will be passed to this method to determine if the assertion passes.
-
-  palindrome = Object.new
-
-  def palindrome.matches?(word)
-    word == word.reverse
-  end
-
-  "abracarba".assert palindrome
-
-== RSpec, Shoulda and other 3rd-Party Matchers 
-
-With tha addition of #matches?, AE supports the same interface for matchers
-as RSpec. Any matcher library designed for use with RSpec should therefore
-be usable with AE as well. This includes RSpecs own matchers and Shoulda's
-excellent Rails matchers.

data/qed/08_check.rdoc

@@ -1,63 +0,0 @@
-== Check Ok/No
-
-The Check library is an optional library that can be used
-to conveniently speed-up construction of reptitive assertions.
-
-To use it, first require the library, then include the mixin
-into the namespace in which you will utilize it.
-
-  require 'ae/check'
-
-  include AE::Check
-
-Now we can define ok/no check procedures. A one-off procedure is
-defined with a block only.
-
-  check do |x, y|
-    x == y
-  end
-
-  ok 1,1
-
-  no 1,2
-
-To define reusable check procedures, give the procedure a name.
-
-  check :palindrome do |x|
-    x.reverse == x
-  end
-
-This will also cause the current check method to be set.
-Later in the code, the check procedure can be reset to this
-by just passing the name.
-
-  check :palindrome
-
-  ok 'abracarba'
-
-  no 'foolishness'
-
-The Check mixin comes preloaded with a few standard checks.
-By default the `:equality` procedure is used.
-
-  check :equality
-
-  ok 1=>1.0
-
-Notice the use of the hash argument here. This is a useful construct for
-many check procedures becuase it it akin to the `#=>` pattern we often
-see in code examples and it also allows for multiple assertions in one call.
-For instance, in the case of `:equality`, multiple entries convey a
-meaning of logical-or.
-
-  ok 1=>2, 1=>1
-
-This would pass becuase the second assertion of equality is true.
-
-Another built in check is `:case_equality` which uses `#===` instead of `#==`
-to make the comparison.
-
-  check :case_equality
-
-  ok 1=>Integer
-