BareTest 0.2 released

Ruby
1

I’m pleased to announce BareTest 0.2.

BareTest is a new test framework. I started writing it for mainly 2
reasons:

  • I disliked the undescriptive way you have specify tests in vanilla
    Test::Unit
    (def test_bla), compared to the much more descriptive way you do it in
    e.g.
    rspec (it “should have a very nice description”)
  • I was pretty sure a decent test framework could be written in under
    100 lines
    of code (and the first version of baretest, written on the flight home
    from
    railsconf09 in vegas, was indeed a whopping 37 lines of code)

By this version, baretest has gotten some - to my knowledge - unique or
at least
rare features. Those include:

  • Very straightforward and terse assertions (just a block whose return
    value
    defines success/failure).
  • Various helpers to write assertions with better diagnostic messages
    and
    more complex tasks like raising, throwing, float imprecision,
    unordered
    collections etc.
  • Easy grouping of assertions into suites.
  • BDD style specifications/test descriptions (NOT code) that can be
    extracted
    without running the testcode.
  • An interactive mode, letting you examine what went wrong in a
    failing/erroring
    test within an irb session, bound to the context of the assertion that
    failed,
    showing you the full code of the assertion, even including it in the
    readline-
    history of that irb session.
  • An uncomplicated way to write pending assertions, have dependency
    testing and
    skip certain suites/assertions.
  • A colored shell formatter, diagnostic-, XML- and TAP formatter.
  • Adding your own formatters is trivial - a module with 4 methods to
    wrap. The
    average formatter shipped with baretest is between 20 and 50 lines.
  • An API to use it from code, such as rake tasks (includes an example
    rake-task)
  • A ‘baretest’ executable to run tests on multiple files at once, using
    a test-
    layout convention to reduce require- and
    setup-path-manipulation-orgies

The Links:
Home: http://projects.sr.brightlight.ch/projects/show/baretest
Github: GitHub - apeiros/baretest: A testframework that doesn't stand in your way or forces you to learn a new language. Two methods is all that is required to know. If you need it, it provides you with all kinds of features to support you writing your tests.
Rubyforge: http://baretest.rubyforge.org
API: http://baretest.rubyforge.org/docs-0.2.0/

How to quickly try baretest without installing it:

  1. Download from github and unpack (or clone) - download link:
    http://github.com/apeiros/baretest/tarball/8954b17def1899a10b0e6fff39ced07f6eb722ef
  2. Change into the baretest directory: cd the/baretest/directory
  3. Run the examples: ./bin/baretest examples/test.rb

That’s it. Alternatively you can run baretest’s own tests, and/or play
with
formatters: ./bin/baretest -f tap

Installing baretest

  1. run gem install baretest (you may have to run sudo gem install baretest)
  2. There is no 2.

Installing baretest edge

  1. Download from github (or clone)
  2. Run rake gem:install (you may have to run sudo rake gem:install)

Note for users with multiple ruby installations: the rake task will try
to use
the right gem executable. You can force it to use a specific one by
setting
the GEM env variable, e.g.: rake gem:install GEM='gem1.9'

Using baretest

  1. In your project directory, run baretest --init, which will create a
    ‘tests’
    directory with all the basic stuff already in it.
  2. Write your tests
  3. Run them using baretest in the toplevel directory of your project.

That’s all folks.
Looking forward to your feedback and hope you enjoy baretest :slight_smile:

Regards
Stefan R., aka apeiros

2

Stefan R. wrote:

By this version, baretest has gotten some - to my knowledge - unique or
at least rare features.

See http://ruby-toolbox.com/categories/testing_frameworks.html

Those include:

  • Very straightforward and terse assertions (just a block whose return
    value defines success/failure).

See assert{ 2.0 } at http://assert2.rubyforge.org/ and also
my Dfect project at detest(1)

  • An interactive mode, letting you examine what went wrong in a
    failing/erroring test within an irb session, bound to the context of
    the assertion that failed, showing you the full code of the assertion,
    even including it in the readline-history of that irb session.

Excellent! This is a very powerful feature. It is also found in Dfect:

detest(1)

Cheers.

3

El Domingo, 25 de Octubre de 2009, Suraj K. escribió:

Excellent! This is a very powerful feature. It is also found in Dfect:

detest(1)

Hi, about Dfect project I’ve open a wish/bug report in Git:
http://github.com/sunaku/dfect/issues/#issue/1

Is it the appropriate place for it? or do you prefer it to be reported
in this
maillist? Thanks.

4

Hi Suraj K.

Thanks for pointing me to the other test frameworks.

See assert{ 2.0 } at http://assert2.rubyforge.org/

As I’ve understood, assert { 2.0 } still uses the method name to
identify what shall be verified. Also it seems to come with its own set
of problems.

my Dfect project at detest(1)

Looks good. But personally, I prefer intuitive method names, and I don’t
think single character method names are intuitive in most cases.
Also, baretest manages to get you all the power you need in only 2
methods :slight_smile:

An example baretest testfile, something I should have added to the first
post already:

examples/test.rb - can be run without installing baretest by

downloading

it from github and run ./bin/baretest examples/test.rb

BareTest.suite do
# assertions and refutations can be grouped in suites. They will
share
# setup and teardown
# they don’t have to be in suites, though
suite “Success” do
assert “An assertion returning a trueish value (non nil/false) is
a success” do
true
end
end

suite "Failure" do
  assert "An assertion returning a falsish value (nil/false) is a

failure" do
false
end
end

suite "Pending" do
  assert "An assertion without a block is pending"
end

suite "Error" do
  assert "Uncaught exceptions in an assertion are an error" do
    raise "Error!"
  end
end

suite "Special assertions" do
  assert "Assert a block to raise" do
    raises do
      sleep(rand()/3+0.05)
      raise "If this raises then the assertion is a success"
    end
  end

  assert "Assert a float to be close to another" do
    a = 0.18 - 0.01
    b = 0.17
    within_delta a, b, 0.001
  end

  suite "Nested suite" do
    assert "Assert two randomly ordered arrays to contain the same

values" do
a = [*“A”…“Z”] # an array with values from A to Z
b = a.sort_by { rand }
equal_unordered(a, b) # can be used with any Enumerable, uses
hash-key identity
end
end
end

suite "Setup & Teardown" do
  setup do
    @foo = "foo"
    @bar = "bar"
  end

  assert "@foo should be set" do
    @foo == "foo"
  end

  suite "Nested suite" do
    setup do
      @bar = "inner bar"
      @baz = "baz"
    end

    assert "@foo is inherited" do
      @foo == "foo"
    end

    assert "@bar is overridden" do
      @bar == "inner bar"
    end

    assert "@baz is defined only for inner" do
      @baz == "baz"
    end
  end

  teardown do
    @foo = nil # not that it'd make much sense, just to demonstrate
  end
end

suite "Dependencies", :requires => ['foo', 'bar'] do
  assert "Will be skipped, due to unsatisfied dependencies" do
    failure "Why the heck do you have a 'foo/bar' file?"
  end
end

end

Regards
Stefan R., (apeiros @ irc.freenode.org & twitter)

5

Stefan R. wrote:

See assert{ 2.0 } at http://assert2.rubyforge.org/

Also it seems to come with its own set of problems.

:slight_smile: Don’t we all?

my Dfect project at detest(1)

Looks good. But personally, I prefer intuitive method names, and I don’t
think single character method names are intuitive in most cases.

Thanks, I agree. That’s why I created emulation layers to mimic
other popular testing libraries, such as Test::Unit and RSpec,
inside Dfect. That way, I can use a similar sugary syntax to
write my tests, but with Dfect running the show under the hood.

Also, baretest manages to get you all the power you need in only 2
methods :slight_smile:

I see more than two methods: suite, assert, failure, raises, etc.

Perhaps I have misunderstood?

An example baretest testfile, something I should have added to the first
post already:
[…]

Thanks for the example. Your method name choices seem very natural.
I think I’ll make an emulation layer for BareTest in Dfect soon.

Cheers.

6

Also, baretest manages to get you all the power you need in only 2
methods :slight_smile:

I see more than two methods: suite, assert, failure, raises, etc.

Perhaps I have misunderstood?

2 Methods is the minimum you need to use it in a productive way: suite
and assert.

There are various more methods, e.g. setup & teardown in suite, and many
predefined helper methods exist in BareTest::Assertion::Support (see
http://baretest.rubyforge.org/docs-0.2.0/BareTest/Assertion/Support.html)

But those are just to make it easier and nicer to write tests. Sugar if
you want.

An example baretest testfile, something I should have added to the first
post already:
[…]

Thanks for the example. Your method name choices seem very natural.
I think I’ll make an emulation layer for BareTest in Dfect soon.

Heh, I’ll be surprised if you manage to emulate it 100%. But I’m
flattered :slight_smile:

Cheers.

To you too. Good luck with DFECT :slight_smile:

Regards
Stefan

7

Iñaki Baz C. wrote:

El Domingo, 25 de Octubre de 2009, Suraj K. escribió:

Excellent! This is a very powerful feature. It is also found in Dfect:

detest(1)

Hi, about Dfect project I’ve open a wish/bug report in Git:
http://github.com/sunaku/dfect/issues/#issue/1

Is it the appropriate place for it?

Yes, that is fine. GitHub notified me about that issue by email.

or do you prefer it to be reported in this maillist? Thanks.

I would prefer the GitHub issue tracker. Thanks for reporting this!