Comments for terrbear.org

Comment on Quick tip: say (OSX) by terry

terry — Tue, 31 Aug 2010 17:32:13 +0000

@Keith
That’s genius!

Comment on Quick tip: say (OSX) by Keith Rarick

Keith Rarick — Tue, 31 Aug 2010 17:01:13 +0000

Or even, in case you leave your computer:

your_command ; curl -d phone=9995551234 http://lostmephone.heroku.com/call

Comment on Months of effort by stinkyskunk

stinkyskunk — Wed, 25 Aug 2010 19:05:49 +0000

you need lysol and antibiotics. just sayin.

Comment on Quick Tips by terry

terry — Thu, 22 Apr 2010 13:58:06 +0000

So I put a lot of debug in it, but here’s what I had leftover:

http://gist.github.com/375257

I had that run before the ParamsParser

Comment on Quick Tips by Eric

Eric — Thu, 22 Apr 2010 00:40:36 +0000

Re: “I wrote some Rack middleware to intercept the parameters…”

I’ve been looking for something like this, any chance you could you post it as a gist or something? Thx.

Comment on Pivotal Pulse and Integrity by Diego Carrion

Diego Carrion — Thu, 01 Apr 2010 15:34:11 +0000

Nice! Will implemented that in Signal

Comment on Machinist + RSpec matcher by terry

terry — Mon, 22 Mar 2010 15:21:16 +0000

@Brian
No. The test is checking that the blueprints for the model work with validations and callbacks.

Comment on Machinist + RSpec matcher by Brian Cardarella

Brian Cardarella — Mon, 22 Mar 2010 14:57:09 +0000

Would it make more sense to test if the Machinist Library is included in ActiveRecord ?

Comment on Machinist + RSpec matcher by terry

terry — Sun, 21 Mar 2010 23:54:27 +0000

@Stephen
3 lines of code, and having to type a description to keep things expressive. I think specs should be expressive, and not “it { model.make_unsaved.should be_valid }*”

So, yes, copying this once to my new projects and keeping everything 1 line of code from there on out is worth it (Callbacks can definitely have problems, and if those show up in your blueprints, your test hasn’t revealed that — the lambda and should_not raise_error gets to be tedious enough and hard enough to decipher that it’s worth abstracting, I think).

Comment on Machinist + RSpec matcher by Stephen Eley

Stephen Eley — Sun, 21 Mar 2010 23:21:01 +0000

Ahh, okay, I get it now. What you’re saying is that you’re not testing Machinist, you’re testing your assumptions about the model (which are reflected in the blueprint.) That makes sense, and I usually do it too for anything non-trivial.

I still think you might have made it a bit too complicated though. I usually assert that expectation with either:

Model.make_unsaved.should be_valid

or:

Model.make.should be_a(Model)

Most often the former, as the way I usually test validation rules is to set up before(:each) block with something like:

before(:each) do
@this = Model.make_unsaved
end

…and then torture the attributes of @this in various ways, verifying each time that the model is no longer valid. An initial “@this.should be_valid” is then sort of necessary to isolate the variables.

Back to the original issue, though: even if the test purpose is sound, making a matcher for it still seems like unnecessary complexity. Your initial example was one line of code. You wrote 20 lines of code, which will presumably be included in a separate file in every future project, so that you could simplify that one line of code into…one line of code.

Granted, the new line of code is prettier than the old. If that’s enough of a win for you to make it worth it, rock on. >8-> (Sometimes it is for me too.)