lemon 0.9.0 → 0.9.2

data/.reap/test.reap

@@ -1,7 +0,0 @@
-
-trip :test do
-  system "lemon -Ilib test/*.rb"
-  system "qed -Ilib qed/"
-  #system "cucumber"
-end
-

data/.ruby

@@ -1,49 +0,0 @@
----
-authors:
-- name: Thomas Sawyer
-  email: transfire@gmail.com
-copyrights:
-- holder: Thomas Sawyer
-  year: '2009'
-  license: BSD-2-Clause
-replacements: []
-conflicts: []
-requirements:
-- name: test
-- name: ae
-- name: ansi
-  version: 1.3+
-- name: detroit
-  groups:
-  - build
-  development: true
-- name: reap
-  groups:
-  - build
-  development: true
-- name: qed
-  groups:
-  - test
-  development: true
-dependencies: []
-repositories:
-- uri: git://github.com/proutils/lemon.git
-  scm: git
-  name: origin
-resources:
-  home: http://rubyworks.github.com/lemon
-  code: http://github.com/rubyworks/lemon
-load_path:
-- lib
-extra:
-  manifest: MANIFEST
-alternatives: []
-revision: 0
-title: Lemon
-summary: Pucker-tight Unit Testing
-description: Lemon is a unit testing framework that tightly correlates class to test
-  case and method to test unit.
-organization: RubyWorks
-version: 0.9.0
-name: lemon
-date: '2011-08-11'

data/Assembly

@@ -1,37 +0,0 @@
----
-email:
-  service : Email
-  file    : ~
-  subject : ~
-  mailto  : 
-    - ruby-talk@ruby-lang.org
-    - rubyworks-mailinglist@googlegroups.com
-  #parts   : [readme]
-  active  : true
-
-gem:
-  active : true
-
-github: {}
-
-dnote:
-  labels   : ~
-  output   : log/DNOTE.rdoc
-
-yard:
-  yardopts: true  
-  priority: 2
-
-qed:
-  files: spec
-
-qedoc:
-  title: Lemony Testing
-  files: spec
-  output: QED.rdoc
-
-vclog:
-  output: 
-    - log/AHISTORY.rdoc
-    - log/CHANGELOG.rdoc
-

data/COPYING.rdoc

@@ -1,33 +0,0 @@
-= COPYRIGHT NOTICES
-
-== Lemon
-
-Copyright:: (c)2009 Thomas Sawyer
-License:: BSD-2-Clause
-Website:: http://rubyworks.github.com/lemon
-
-    Copyright 2009 Thomas Sawyer. All rights reserved.
-
-    Redistribution and use in source and binary forms, with or without modification, are
-    permitted provided that the following conditions are met:
-
-       1. Redistributions of source code must retain the above copyright notice, this list of
-          conditions and the following disclaimer.
-
-       2. Redistributions in binary form must reproduce the above copyright notice, this list
-          of conditions and the following disclaimer in the documentation and/or other materials
-          provided with the distribution.
-
-    THIS SOFTWARE IS PROVIDED BY Thomas Sawyer ``AS IS'' AND ANY EXPRESS OR IMPLIED
-    WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
-    FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Thomas Sawyer OR
-    CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
-    CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-    SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-    ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
-    NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
-    ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-    The views and conclusions contained in the software and documentation are those of the
-    authors and should not be interpreted as representing official policies, either expressed
-    or implied, of Thomas Sawyer.

data/MANIFEST

@@ -1,55 +0,0 @@
-#!mast .yardopts .ruby bin demo lib man qed spec test try [A-Z][A-Z]*
-.yardopts
-.ruby
-bin/lemonade
-lib/lemon/ae.rb
-lib/lemon/cli/base.rb
-lib/lemon/cli/coverage.rb
-lib/lemon/cli/generate.rb
-lib/lemon/cli/test.rb
-lib/lemon/cli.rb
-lib/lemon/core_ext/kernel.rb
-lib/lemon/core_ext/omission.rb
-lib/lemon/core_ext.rb
-lib/lemon/coverage/analyzer.rb
-lib/lemon/coverage/cover_unit.rb
-lib/lemon/coverage/formats/abstract.rb
-lib/lemon/coverage/formats/compact.rb
-lib/lemon/coverage/formats/outline.rb
-lib/lemon/coverage/formats/verbose.rb
-lib/lemon/coverage/formats/yaml.rb
-lib/lemon/coverage/snapshot.rb
-lib/lemon/coverage/source_parser.rb
-lib/lemon/generator.rb
-lib/lemon/test_advice.rb
-lib/lemon/test_case.rb
-lib/lemon/test_class.rb
-lib/lemon/test_method.rb
-lib/lemon/test_module.rb
-lib/lemon/test_proc.rb
-lib/lemon/test_setup.rb
-lib/lemon/test_world.rb
-lib/lemon.rb
-lib/lemon.yml
-spec/applique/fs.rb
-spec/coverage/01_complete.rdoc
-spec/coverage/02_incomplete.rdoc
-spec/coverage/03_extensions.rdoc
-spec/coverage/applique/lemon.rb
-try/.test
-try/case_error.rb
-try/case_fail.rb
-try/case_pass.rb
-try/case_pending.rb
-try/case_singleton.rb
-try/case_untested.rb
-try/fixtures/calculator.rb
-try/fixtures/example-use.rb
-try/fixtures/example.rb
-try/helpers/loadpath.rb
-HISTORY.rdoc
-PROFILE
-QED.rdoc
-README.md
-VERSION
-COPYING.rdoc

data/PROFILE

@@ -1,30 +0,0 @@
---- 
-title  : Lemon
-summary: Pucker-tight Unit Testing
-authors:
-  - Thomas Sawyer <transfire@gmail.com>
-
-description:
-  Lemon is a unit testing framework that tightly correlates
-  class to test case and method to test unit.
-
-resources:
-  home: http://rubyworks.github.com/lemon
-  code: http://github.com/rubyworks/lemon
-
-repositories:
-  origin: git://github.com/proutils/lemon.git
-
-requirements:
-  - test
-  - ae
-  - ansi 1.3+
-  - detroit  (build)
-  - reap     (build)
-  - qed      (test)
-
-organization: RubyWorks
-
-copyright: Copyright 2009 Thomas Sawyer
-license: BSD-2-Clause
-

data/Rakefile

@@ -1,23 +0,0 @@
-#!/usr/bin/env ruby
-
-require 'test/rake'
-
-Test::Rake::TestTask.new do |t|
-  t.libs  << 'test/fixtures'
-  t.tests << 'test/*.rb'
-end
-
-namespace :test do
-
-  desc 'run lemon unit tests (via shell command)'
-  task :unit do
-    sh 'lemonade test -Itest/fixtures test/*.rb'
-  end
-
-  desc 'run qed demonstration tests'
-  task :qed do
-    sh 'qed -Ilib spec/'
-  end
-
-end
-

data/VERSION

@@ -1 +0,0 @@
-0.9.0

data/lib/lemon/core_ext/omission.rb

@@ -1,18 +0,0 @@
-# The Omission class is a subclass of NotImplementedError with 
-# it's assertion flag set to true. This will be recognized by
-# Ruby Test as a test omission.
-#
-# @example
-#   test "some feature" do
-#     raise Omission, "feature can't be tested"
-#   end
-#
-class Omission < NotImplementedError
-  def assertion?
-    true
-  end
-  def to_proc
-    error = self
-    lambda{ raise error }
-  end
-end

data/lib/lemon/generator.rb

@@ -1,149 +0,0 @@
-module Lemon
-
-  require 'lemon/coverage/analyzer'
-
-  #--
-  # TODO: Generator options for selecting all, covered and uncovered still
-  #       need some clarification.
-  #++
-
-  # Test Scaffold Generator.
-  #
-  class Generator
-
-    # New Scaffold Generator.
-    #
-    # @option options [Array] :namespaces
-    #   List of class/module names to limit scaffolding.
-    #
-    # @option options [Boolean] :private
-    #   Include private methods in scaffolding.
-    #
-    # @option options [Boolean] :covered
-    #   Include covered targets in scaffolding.
-    #
-    # @option options [Boolean] :uncovered
-    #   Include uncovered targets in scaffolding.
-    #
-    # @option options [Boolean] :all
-    #   Include all possible targets in scaffolding.
-    #
-    def initialize(files, options={})
-      @files      = files
-
-      @coverage   = CoverageAnalyzer.new(files, options)
-      @suite      = @coverage.suite
-
-      @namespaces = options[:namespaces]
-      @private    = options[:private]
-      @covered    = options[:covered]
-      @uncovered  = options[:uncovered]
-      @all        = options[:all]
-
-      if @namespaces
-        unless @covered or @uncovered
-          @all = true 
-        end
-      end
-
-    end
-
-    # Returns CoverageAnalyzer instance.
-    def coverage
-      @coverage
-    end
-
-    # List of class and module namespaces to limit scaffolding.
-    def namespaces
-      @namespaces
-    end
-
-    # Include all targets.
-    def all?
-      @all
-    end
-
-    # Include targets that are already covered.
-    def covered?
-      @covered
-    end
-
-    # Include only uncovered targrts.
-    def uncovered?
-      @uncovered
-    end
-
-    # Include private and protected methods.
-    def private?
-      @private
-    end
-
-    # Generate test template(s).
-    def generate
-      if all?
-        generate_all
-      elsif uncovered?
-        generate_uncovered
-      else
-        generate_target
-      end
-    end
-
-    # Generate code template for covered.
-    def generate_target
-      render(filter(coverage.target.units))
-    end
-
-    # Generate code template for uncovered.
-    def generate_uncovered
-      render(filter(coverage.uncovered))
-    end
-
-    # Generate code template for all.
-    def generate_all
-      render(Snapshot.capture(namespaces).units)
-    end
-
-    # Filter targets to include only specified namespaces.
-    def filter(units)
-      return units if namespaces.nil? or namespaces.empty?
-      units.select do |u|
-        namespaces.any? do |ns|
-          /^#{ns}/ =~ u.namespace.to_s
-        end
-      end
-    end
-
-    # Generate code template.
-    def render(units)
-      code = []
-      mods = units.group_by{ |u| u.namespace }
-      mods.each do |mod, units|
-        if Class === mod
-          code << "TestClass #{mod} do"
-        else
-          code << "TestModule #{mod} do"
-        end
-        units.each do |unit|
-          next unless private? or unit.public?
-          if unit.function?
-            code << "\n  ClassMethod :#{unit.method} do"
-            code << "\n    Test '' do"
-            code << "\n    end"
-            code << "end"
-          else
-            code << "\n  Method :#{unit.method} do"
-            code << "\n    Test '' do"
-            code << "\n    end"
-            code << "\n  end"
-          end
-        end
-        code << "\nend\n"
-      end
-
-      code.join("\n")
-    end
-
-  end
-
-end

data/lib/lemon.yml

@@ -1,49 +0,0 @@
----
-authors:
-- name: Thomas Sawyer
-  email: transfire@gmail.com
-copyrights:
-- holder: Thomas Sawyer
-  year: '2009'
-  license: BSD-2-Clause
-replacements: []
-conflicts: []
-requirements:
-- name: test
-- name: ae
-- name: ansi
-  version: 1.3+
-- name: detroit
-  groups:
-  - build
-  development: true
-- name: reap
-  groups:
-  - build
-  development: true
-- name: qed
-  groups:
-  - test
-  development: true
-dependencies: []
-repositories:
-- uri: git://github.com/proutils/lemon.git
-  scm: git
-  name: origin
-resources:
-  home: http://rubyworks.github.com/lemon
-  code: http://github.com/rubyworks/lemon
-load_path:
-- lib
-extra:
-  manifest: MANIFEST
-alternatives: []
-revision: 0
-title: Lemon
-summary: Pucker-tight Unit Testing
-description: Lemon is a unit testing framework that tightly correlates class to test
-  case and method to test unit.
-organization: RubyWorks
-version: 0.9.0
-name: lemon
-date: '2011-08-11'

data/notes/2010-05-05-coverage.rdoc

@@ -1,47 +0,0 @@
-= 2010-05-05 Getting Good Coverage
-
-Getting good coverage analysis is not easy. The difficulty comes
-is determining what is of interest to the tests and what
-is not. That isn't so hard with completely new code, but
-core extensions, for instance, are challenging to isolate
-from original methods.
-
-Thee issue can mostly be taken care of by taking a canonical
-snapshot of the system before loading the tests. Then taking
-a snapshot after loading the tests and comparing the two.
-For the most part the difference will be the code in need of
-coverage.
-
-Unfortunately helper code still gets in the way of taking these
-snapshots. As a result I have determined there are only four
-possible complete solutions.
-
-1) Use a Ruby lexer/parser to syntatically deconstruct the
-target libraries. This is a complex solution, and not one
-I relish trying.
-
-2) All helpers must go in special files that are preloaded so
-the snapshot can isolate it from the actual target code. This
-means any mocks, for instance, would have to be defined in
-separate files for the the test(s) that might use them. This
-solution it good in that it actually encourges the writing
-reusable helper code, but it can be annoying when writting
-one-off mocks and such.
-
-3) As an alternate to #2, Lemon could provide a method
-for specifying that a class/module or method is a helper
-and can simply be ignored when analysing coverage.
-
-4) Lastly, the library file being covered can be specified
-with a special method, e.g. #Covers. The method would act
-just like +#require+ except that it takes a snapshot before and
-after the loading the library, and in this way builds up
-a table of proper coverage targets.
-
-Options #2 and #3 have proven lack luster. It's simply too
-much overhead involved to get good coverage. Option #4 is the most
-robust choice. Unfortunately coverage reports can be very slow
-if there are lot of files to cover --Snapshots can take a second
-or two to create. Hopefully it can be sped up with refinement,
-but at the very least the coverage reporting if optional.
-

data/notes/2010-05-06-files-not-classes.rdoc

@@ -1,19 +0,0 @@
-= 2010-05-06 Files, Not Classes
-
-Just had a realization about my approch to Lemon tests.
-Until now I have equated the test-case to the class/module
-and the test-unit to the method. That makes sense, but it means
-I have left out a very important factor in the the design
-of tests: the file.
-
-I had defined a test-suite as the entire set of tests to
-be run. But I think now I am mistaken. The suite should
-correspond to the fiel being tested. Often that will mean
-one test-case per test-suite, but that's okay.
-
-After the next release, 0.7.0, I will implement this
-refactorization. I beleive it should ultimately help
-improve test coverage as well.
-
-
-

data/notes/2010-07-11-acid-testing.rdoc

@@ -1,52 +0,0 @@
-= 2010-07-11 | Kool-Aid 
-
-Taking Unit Testing to the next level with a dab of DBC.
-
-Say we have,
-
-  class K
-
-    def f1(a1)
-      g1(a1)
-    end
-
-    def g1(a1)
-      a1 + 1
-    end
-
-  end
-
-Now what do we want to say about K#f1?
-
-  unit K, :f1 do |a|
-    case a
-    when 1
-      result do |r|
-        r.assert == 2
-      end
-    end
-  end
-
-Now later we induce labor.
-
-  k = K.new
-  k.f1(1)
-
-It does't really matter what the result class contains, or how it 
-even gets called. Thus it can test side-effects as well as simple
-functional results.
-
-Okay, so how do we implement this?
-
-  class K
-
-    alias "f1:lemon", :f1
-
-    def f1(a1)
-      Lemon.verify_unit(binding) do
-        send("f1:lemon", a1)
-      end
-    end
-
-  end
-

data/notes/2010-08-02-enforcing-the-unit.md

@@ -1,68 +0,0 @@
-2010-08-02 | Enforcing the Unit
-
-The current API for creating a Lemon unit testcase looks like this:
-
-    covers 'someclass'
-
-    testcase SomeClass do
-
-      unit :some_method => "does something or another" do
-        # ...
-      end
-
-    end
-
-As it currentlt standa the current design is little more than a means of
-organization, orienting the developer to think in terms of test units.
-What is does not do is enforce the actual testing the the unit referenced.
-We could put any old mess in the unit block and as long as it did not raise
-an exception, it would get a *pass*.
-
-Taking some time to consider this in depth, I've concieved of a way in which
-that use of the method could in fact be enforced.
-
-    covers 'someclass'
-
-    testcase SomeClass do
-
-      setup do
-        SomeClass.new
-      end
-
-      unit :some_method => "does something or another" do |unit|
-        unit.object      # object from setup
-        unit.call(...)   # calls #some_method on unit.object
-      end
-
-    end
-
-What is intersting about this, beyond that fact that it enforces the use of
-the class or module and method involved, but that it also does so in
-a way naturally suited to mocking --the `unit` delegator could even have
-mocking methods built-in.
-
-      unit :some_method => "does something or another" do |unit|
-        unit.receives.foo(:bar)  # object from setup would receive this call
-        unit.returns(:baz)       # the subsequent #call will return this
-        unit.call(...)           # calls #some_method on unit.object
-      end
-
-On the downside this approach limits what can be done in the unit block.
-One _has_ to utilize the object as defined in `setup` and one _has_ to invoke
-the unit method via the `#call` interface. Though, I suppose one could argue
-that these limitations are a good thing, as they help the unit stay narrowly
-focused on that goal at hand.
-
-I think this approach is worth considering for a possible furture version.
-Perhaps a "Lemon 2.0". For the time being I believe we can enforce the unit
-without resorting this major API change.
-
-The next release of Lemon will temporarily override the unit method on the
-target class for each unit execution. If the unit method gets called within
-the unit block, then it will be noted by the overridden method before passing
-off to the original definition. The approach is perhaps a bit draconian, and 
-is certainly only possible thanks to the remarkable dynamicism of Ruby, but
-it should work perfectly well. So now, if the target method is not called within
-the taget block, the unit will raise a Pending exception, regardless of the 
-code in the block. Unit Enforced!
-

data/notes/2010-08-03-new-api.md

@@ -1,37 +0,0 @@
-# 2010-08-03 | A New API
-
-Simplified API. There is one main method.
-
-  unit_test SomeClass, :some_method, "description" do
-    # test ...
-  end
-
-It will be a global method. The block notations would still work, but
-they would simple become wrappers for the main method.
-
-  testcase SomeClass do
-
-    unit :some_method, "description" do
-
-    end
-
-  end
-
-If I can make it backward compatible, I may also allow something like:
-
-  testcase SomeClass do
-
-    unit :some_method do
-
-      concern "description" do
-
-      end
-
-    end
-
-  end
-
-By using this global method, I should be able to simplify the underlying
-implementation a great deal, which has been major concern about Lemon
-as of late.
-

data/notes/2011-07-07-nailing-down-the-nomenclature.md

@@ -1,6 +0,0 @@
-# 2011-07-07 | Nailing Down the Nomenclature
-
-I have finally settled on `test_class` and `test_module` as thew new toplevel method for defining Lemon test cases. I decided against reusing `test_case` from Citron b/c I determined it is best that these types of test cases not be mixed together, but rather stay cleanly separated.
-
-I also decided against the original KO inspired nomenclature of `Test.case`. Though it looks very cool at first glance, in the end it goes against the grain. For instance, would one design an RSpec-stlye nomenclature as `Test.describe`, or a Cucumber-style nomenclature using `Test.feature`? While one could do so, it's completely uneccessry.
-