[ANN] BareTest 0.2 released

[apeiros]

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: http://github.com/apeiros/baretest
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

Regards
Stefan Rusterholz, aka apeiros

 

[Suraj Kurapati]

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 http://snk.tuxfamily.org/lib/dfect/

* 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:

http://snk.tuxfamily.org/lib/dfect/#Motivation

Cheers.

 

[Iñaki Baz Castillo]

El Domingo, 25 de Octubre de 2009, Suraj Kurapati escribi=C3=B3:

Excellent! This is a very powerful feature. It is also found in Dfect:
=20
http://snk.tuxfamily.org/lib/dfect/#Motivation

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 t=
his=20
maillist? Thanks.


=2D-=20
I=C3=B1aki Baz Castillo <[email protected]>

 

[Suraj Kurapati]

El Domingo, 25 de Octubre de 2009, Suraj Kurapati escribió:

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!

 

[apeiros]

Hi Suraj Kurapati

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 http://snk.tuxfamily.org/lib/dfect/

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

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 Rusterholz, (apeiros @ irc.freenode.org & twitter)

 

[Suraj Kurapati]

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

Don't we all?

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

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.

 

[apeiros]

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

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

Cheers.

To you too. Good luck with DFECT

Regards
Stefan