# BareTest 0.2 released

**URL:** <https://www.ruby-forum.com/t/baretest-0-2-released/177853>\
**Category:** Ruby\
**Created:** [October 25, 2009, 2:28pm UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853 "2009-10-25T14:28:22Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 25, 2009, 2:28pm UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/1 "2009-10-25T14:28:22Z")

</div>

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](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.](http://github.com/apeiros/baretest)  
Rubyforge: [http://baretest.rubyforge.org](http://baretest.rubyforge.org)  
API: [http://baretest.rubyforge.org/docs-0.2.0/](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](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 R., aka apeiros

---

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 25, 2009, 6:46pm UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/2 "2009-10-25T18:46:15Z")

</div>

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](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/](http://assert2.rubyforge.org/) and also  
my Dfect project at [detest(1)](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:

[detest(1)](http://snk.tuxfamily.org/lib/dfect/#Motivation)

Cheers.

---

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 26, 2009, 11:46am UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/3 "2009-10-26T11:46:42Z")

</div>

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)](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](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.

---

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 27, 2009, 11:17am UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/4 "2009-10-27T11:17:37Z")

</div>

Hi Suraj K.

Thanks for pointing me to the other test frameworks.

> See assert{ 2.0 } at [http://assert2.rubyforge.org/](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)](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 R., (apeiros @ [irc.freenode.org](http://irc.freenode.org) & twitter)

---

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 27, 2009, 6:25pm UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/5 "2009-10-27T18:25:59Z")

</div>

Stefan R. wrote:

> > See assert{ 2.0 } at [http://assert2.rubyforge.org/](http://assert2.rubyforge.org/)
> 
> Also it seems to come with its own set of problems.

🙂 Don’t we all?

> > my Dfect project at [detest(1)](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.

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.

---

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 27, 2009, 8:30pm UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/6 "2009-10-27T20:30:18Z")

</div>

> > 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?

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](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

---

<div class="post-metadata">

**Author:** ![apeiros](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/838e76/32.png) [@apeiros](https://www.ruby-forum.com/u/apeiros)\
**Post date:** [October 26, 2009, 5:51pm UTC](https://www.ruby-forum.com/t/baretest-0-2-released/177853/7 "2009-10-26T17:51:12Z")

</div>

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)](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](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!