In Files

  • minitest/spec.rb

Class/Module Index [+]

Quicksearch

MiniTest::Spec

MiniTest::Spec -- The faster, better, less-magical spec framework!

For a list of expectations, see MiniTest::Expectations.

Constants

TYPES

Contains pairs of matchers and Spec classes to be used to calculate the superclass of a top-level describe. This allows for automatically customizable spec types.

See: ::register_spec_type and ::spec_type

Public Class Methods

after(type = nil, &block) click to toggle source

Define an ‘after’ action. Inherits the way normal methods should.

NOTE: type is ignored and is only there to make porting easier.

Equivalent to MiniTest::Unit::TestCase#teardown.

 
               # File minitest/spec.rb, line 178
def self.after type = nil, &block
  define_method :teardown do
    self.instance_eval(&block)
    super()
  end
end
            
before(type = nil, &block) click to toggle source

Define a ‘before’ action. Inherits the way normal methods should.

NOTE: type is ignored and is only there to make porting easier.

Equivalent to MiniTest::Unit::TestCase#setup.

 
               # File minitest/spec.rb, line 164
def self.before type = nil, &block
  define_method :setup do
    super()
    self.instance_eval(&block)
  end
end
            
children() click to toggle source

Returns the children of this spec.

 
               # File minitest/spec.rb, line 147
def self.children
  @children ||= []
end
            
it(desc = "anonymous", &block) click to toggle source

Define an expectation with name desc. Name gets morphed to a proper test method name. For some freakish reason, people who write specs don’t like class inheritence, so this goes way out of its way to make sure that expectations aren’t inherited.

This is also aliased to specify and doesn’t require a desc arg.

Hint: If you do want inheritence, use minitest/unit. You can mix and match between assertions and expectations as much as you want.

 
               # File minitest/spec.rb, line 196
def self.it desc = "anonymous", &block
  block ||= proc { skip "(no tests defined)" }

  @specs ||= 0
  @specs += 1

  name = "test_%04d_%s" % [ @specs, desc ]

  define_method name, &block

  self.children.each do |mod|
    mod.send :undef_method, name if mod.public_method_defined? name
  end

  name
end
            
let(name, &block) click to toggle source

Essentially, define an accessor for name with block.

Why use let instead of def? I honestly don’t know.

 
               # File minitest/spec.rb, line 218
def self.let name, &block
  define_method name do
    @_memoized ||= {}
    @_memoized.fetch(name) { |k| @_memoized[k] = instance_eval(&block) }
  end
end
            
register_spec_type(*args, &block) click to toggle source

Register a new type of spec that matches the spec’s description. This method can take either a Regexp and a spec class or a spec class and a block that takes the description and returns true if it matches.

Eg:

register_spec_type(/Controller$/, MiniTest::Spec::Rails)

or:

register_spec_type(MiniTest::Spec::RailsModel) do |desc|
  desc.superclass == ActiveRecord::Base
end
 
               # File minitest/spec.rb, line 115
def self.register_spec_type(*args, &block)
  if block then
    matcher, klass = block, args.first
  else
    matcher, klass = *args
  end
  TYPES.unshift [matcher, klass]
end
            
spec_type(desc) click to toggle source

Figure out the spec class to use based on a spec’s description. Eg:

spec_type("BlahController") # => MiniTest::Spec::Rails
 
               # File minitest/spec.rb, line 129
def self.spec_type desc
  TYPES.find { |matcher, klass|
    if matcher.respond_to? :call then
      matcher.call desc
    else
      matcher === desc.to_s
    end
  }.last
end
            
subject(&block) click to toggle source

Another lazy man’s accessor generator. Made even more lazy by setting the name for you to subject.

 
               # File minitest/spec.rb, line 229
def self.subject &block
  let :subject, &block
end
            

Commenting is here to help enhance the documentation. For example, code samples, or clarification of the documentation.

If you have questions about Ruby or the documentation, please post to one of the Ruby mailing lists. You will get better, faster, help that way.

If you wish to post a correction of the docs, please do so, but also file bug report so that it can be corrected for the next release. Thank you.

If you want to help improve the Ruby documentation, please visit Documenting-ruby.org.

blog comments powered by Disqus