Posts tagged bdd

Jul04

RSpec stub_chain

bdd | comments

class Widget
  def foo
    bar.baz.fourty_two
  end
end

describe Widget
  it "runs a method chain" do
    widget = Widget.new
    widget.stub_chain(:bar, :baz, :fourty_two => 42)
    widget.foo.should == 42
  end
end
Continue reading »

Apr10

"Should" In Specs

bdd | comments

Why repeat “should” over and over again in your specs? I prefer not to do this:

it "should throw an exception"
it "should not run if already running"
it "should prevent duplicate access"
Continue reading »

Mar20

Testing Doesn't Require a Test Framework

bdd | comments

You can practice TDD/BDD anywhere, whether or not you have a test framework available to you. For example, here’s a fragment of test.c from an Nginx module I wrote a few years ago:

Continue reading »

Jul06

The End of Bugs?

bdd | comments

Although I’ve been a believer in TDD/BDD for quite a while, rush was the first time I started a project and said, ok, THIS time I’m going to get really serious about it. My very first commit was a bunch of empty specs, and since then, I don’t think I’ve committed any new feature or even a bugfix without an accompanying spec.

Continue reading »

May02

Rocking the Mocking

bdd | comments

How do you write a spec for this method without touching the filesystem or the user’s environment?

def authkey
  File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")
end
Continue reading »

Apr22

Why No Love For RSpec?

bdd rspec rubinius | comments

It’s no secret that I’m a big RSpec fan. Test::Unit feels pretty outdated these days, and none of the other frameworks can yet match the level of BDD goodness you get from RSpec. Throw in that it’s now a mature and stable library, and it seems like a sure bet for all your Ruby specing (or testing, if you like) needs.

Continue reading »

Mar15

One Expectation Per Spec

bdd | comments

Jay Fields posts about one expectation per spec, something that I generally agree with but often find hard to practice. I typically find myself with one mock and one assert per test, such as this example from the rush specs:

Continue reading »

Feb23

Test Assumptions, Not Methods

bdd | comments

Specs should test assumptions, not methods.

How many specs should there be for each method? One per assumption. For example, this method:

Continue reading »

Feb07

Minimalist RSpec Matching

bdd | comments

I’ve been thinking about the “too much magic” problem of RSpec. There are two sides to this: too much magic in its internals, and too much magic in its matcher syntax. These are related. Shoulda and test_spec are popular because people like asserts. You never forget the syntax for assert_equals - at least, once you can remember the order the arguments go in (I always want to write the value first and the expected value second).

Continue reading »

Feb02

Theory vs Practice

methodology bdd | comments

Specs (or tests) show that your code works in theory. A running app in production shows that your code works in practice.

Continue reading »

Jan25

Rake Task To Port Your Unit Tests to RSpec Specs

bdd | comments

Put `test_port_spec.rake` into lib/tasks, then run rake test:port:spec. It doesn’t delete the tests it ports; this way you get the joy of typing rm -rf test yourself.

Jan16

Ruby Test Framework Roundup and Musings

bdd | comments

Last week’s icanhasruby had a series of presentations themed around test setups. The main lesson I took away from this is that a single best-practice solution to test/behavior-driven development has not yet been found. But I get the sense that the community is zeroing in on some core concepts that may one day be as ubiquitous as MVC or the HTTP request/response cycle. Even more interesting is that this seems to be happening in a completely decentralized way. I’m not sure where the Rails core team stands, but, given that they are continuing to put work behind Test::Unit (which, as near as I can tell, has been unmaintained since 2003), they don’t seem to be participating much in this quiet BDD revolution. But part of the beauty of Rails and Ruby is that they don’t need to.

Continue reading »