Forum: Ruby Should is the new Must?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Thomas S. (Guest)
on 2008-11-18 15:13
(Received via mailing list)
Why did 'should' become the going nomenclature of BDD framworks?

'Should' connotes 'ought', as if something ought to do xyz, but
doesn't necessarily have to. I don't know about you, but I don't write
my tests/specs that way!

'Must' is the word that denotes what our tests/specs do.

  my_method.must.do_the_right_thing

not

  my_method.should.do_the_right_thing

'Must' is a shorter word too. So why didn't it become the word of
choice here?

I think long dead Grammar teachers are rolling in their graves.


-7. Muse.
Charles Oliver N. (Guest)
on 2008-11-18 15:35
(Received via mailing list)
Trans wrote:
> Why did 'should' become the going nomenclature of BDD framworks?
>
> 'Should' connotes 'ought', as if something ought to do xyz, but
> doesn't necessarily have to. I don't know about you, but I don't write
> my tests/specs that way!
>
> 'Must' is the word that denotes what our tests/specs do.

I agree. I've suggested the classic requirement-docs' "shall" in the
past too, but "must" has an immediacy more appropriate to BDD.

- Charlie
Stephen C. (Guest)
on 2008-11-18 15:46
(Received via mailing list)
Hi,

On Nov 18, 2008, at 7:09 AM, Trans wrote:

> not
>
>  my_method.should.do_the_right_thing
>
> 'Must' is a shorter word too. So why didn't it become the word of
> choice here?

Perhaps because even we programmers are fallible, and it softens the
blow when specs fail. Ah! "my_method" is acting up again!

Stephen
Einar Magnús Boson (Guest)
on 2008-11-18 15:50
(Received via mailing list)
But you are setting up an expectation, right?

my_method.must.do_the_right_thing.
it didn't? but it must!

my_method.should.do_the_right_thing.
it didn't, but it should!

For me the second example feels more natural in a environment where
you expect tests to fail at first, maybe this is different in BDD than
in TDD, I don't know enough about BDD. Especially when you use tests
to design interfaces the "should" thinking comes more natural: You
don't have a feature yet but you write down what it should do, then
you implement it.




On 18.11.2008, at 13:30 , Charles Oliver N. wrote:

>
> - Charlie
>

einarmagnus
Charles Oliver N. (Guest)
on 2008-11-18 16:01
(Received via mailing list)
Stephen C. wrote:
> Perhaps because even we programmers are fallible, and it softens the
> blow when specs fail. Ah! "my_method" is acting up again!

How about something a bit more threatening...

my_method.better == 42

Perhaps you define an or_else {} along with the spec that cuts off the
programmer's little finger?

- Charlie
Tobias Crawley (Guest)
on 2008-11-18 16:28
(Received via mailing list)
On Nov 18, 2008, at 8:46 AM, Einar Magnús Boson wrote:

> than in TDD, I don't know enough about BDD. Especially when you use
> tests to design interfaces the "should" thinking comes more natural:
> You don't have a feature yet but you write down what it should do,
> then you implement it.

Announcing yet another test framework: Musty!

Its perfect for dusting off that old, untested code and bringing it
into the modern era! Since its already in production, it MUST be doing
the right thing already, right?

-Tobias
Paul B. (Guest)
on 2008-11-18 16:57
(Received via mailing list)
On Tue, Nov 18, 2008 at 10:57:28PM +0900, Charles Oliver N. wrote:
> How about something a bit more threatening...
>
> my_method.better == 42

well.daggum do
  my_cotton_pickin_variable.oughta == 13
end
Charles Oliver N. (Guest)
on 2008-11-18 17:19
(Received via mailing list)
Paul B. wrote:
> well.daggum do
>   my_cotton_pickin_variable.oughta == 13
> end

Maybe we could get really fuzzy with it...

my_method.might == 3

I've been on a few projects where that would be a valid spec.

- Charlie
Daniel B. (Guest)
on 2008-11-18 18:22
(Received via mailing list)
On Nov 18, 6:09 am, Trans <removed_email_address@domain.invalid> wrote:
> Why did 'should' become the going nomenclature of BDD framworks?

Dunno. Don't care. I don't feel the need for DSL-y notation in my
tests.

assert_rocks(Test::Unit) # Test::Unit 2 anyway

Regards,

Dan
Ara H. (Guest)
on 2008-11-18 19:29
(Received via mailing list)
On Nov 18, 2008, at 9:18 AM, Daniel B. wrote:

> Dunno. Don't care. I don't feel the need for DSL-y notation in my
> tests.
>
> assert_rocks(Test::Unit) # Test::Unit 2 anyway
>
> Regards,
>
> Dan
>


i'm with you dan - the fact that 'should' somehow produces better code
that 'assert' is plain crazy.  so is changing a T(DD) to a B.


a @ http://codeforpeople.com/
Ara H. (Guest)
on 2008-11-18 19:55
(Received via mailing list)
On Nov 18, 2008, at 6:30 AM, Charles Oliver N. wrote:

> I agree. I've suggested the classic requirement-docs' "shall" in the
> past too, but "must" has an immediacy more appropriate to BDD.


should makes sense from a 'write the tests first' perspective.  still
don't like it - but just saying... ;-)

a @ http://codeforpeople.com/
Joshua B. (Guest)
on 2008-11-18 21:02
(Received via mailing list)
Thanks for the coffee all over my desk via my nose!

Im_gonna_make_you_an_offer_you_cant_refuse do
   my_method.better know_when_to_shut_up
or_else
   sleep_with_the_fishes
end

def sleep_with_the_fishes
   puts "Why do you hurt me?"
end

- Josh
Daniel B. (Guest)
on 2008-11-19 01:17
(Received via mailing list)
On Nov 18, 10:25 am, "ara.t.howard" <removed_email_address@domain.invalid> 
wrote:
>
> i'm with you dan - the fact that 'should' somehow produces better code  
> that 'assert' is plain crazy.  so is changing a T(DD) to a B.

I think Shoulda can create a printable, formatable spec from the tests
themselves that PM's can easily read. Or is that RSpec? Or do either
of them have that feature? I thought one of them did.

That's about the only practical advantage I can see. And, I think
that's something that could be integrated into Test::Unit if we really
wanted it.

Regards,

Dan
Ara H. (Guest)
on 2008-11-19 04:18
(Received via mailing list)
On Nov 18, 2008, at 4:12 PM, Daniel B. wrote:

> I think Shoulda can create a printable, formatable spec from the tests
> themselves that PM's can easily read. Or is that RSpec? Or do either
> of them have that feature? I thought one of them did.
>

you mean as opposed to reading the *actual* spec right?  (aka the
code)  ;-)

sorry - couldn't resist.

> That's about the only practical advantage I can see. And, I think
> that's something that could be integrated into Test::Unit if we really
> wanted it.

indeedy.  and change T to B while you're at it.  much more efficient
and speedy.

a @ http://codeforpeople.com/
Daniel B. (Guest)
on 2008-11-19 04:26
(Received via mailing list)
ara.t.howard wrote:
>
> On Nov 18, 2008, at 4:12 PM, Daniel B. wrote:
>
>> I think Shoulda can create a printable, formatable spec from the tests
>> themselves that PM's can easily read. Or is that RSpec? Or do either
>> of them have that feature? I thought one of them did.
>>
>
> you mean as opposed to reading the *actual* spec right?  (aka the code)
> ;-)

Who are these PM's who can read code? ;)

> sorry - couldn't resist.

No problem. ;)

Hm, random idea here...if specs were formalized somehow...then we could
autogenerate a test spec from the written spec and vice-versa. A bridge
between
PM's and programmers. Something like UML, but for tests...

I dunno...just a thought. Maybe it already exists?

>> That's about the only practical advantage I can see. And, I think
>> that's something that could be integrated into Test::Unit if we really
>> wanted it.
>
> indeedy.  and change T to B while you're at it.  much more efficient and
> speedy.

:-P

Speaking of efficiency and speed I highly recommend people upgrade to
Test::Unit
2.x. The startup and shutdown methods alone are worth it, as they could
save
many, many calls that you would otherwise shove in a setup method.

Regards,

Dan
Mikel L. (Guest)
on 2008-11-19 17:35
(Received via mailing list)
On Wed, Nov 19, 2008 at 1:53 AM, Paul B. <removed_email_address@domain.invalid>
wrote:

> well.daggum do
>  my_cotton_pickin_variable.oughta == 13
> end
>

That thar last spec went n' failed with
my_cotton_pickin_variable.oughta == 13but the son of a gun came back
with 3
Avdi G. (Guest)
on 2008-11-19 20:55
(Received via mailing list)
On Tue, Nov 18, 2008 at 9:21 PM, Daniel B. 
<removed_email_address@domain.invalid>
wrote:
> Hm, random idea here...if specs were formalized somehow...then we could
> autogenerate a test spec from the written spec and vice-versa. A bridge
> between PM's and programmers. Something like UML, but for tests...
>
> I dunno...just a thought. Maybe it already exists?

It's called FIT[1], or, in the Ruby world, Cucumber[2] (successor to
the RSpec Story Runner).

[1] http://fit.c2.com/
[2] http://github.com/aslakhellesoy/cucumber/wikis
Avdi G. (Guest)
on 2008-11-19 21:00
(Received via mailing list)
On Tue, Nov 18, 2008 at 8:09 AM, Trans <removed_email_address@domain.invalid> 
wrote:
> Why did 'should' become the going nomenclature of BDD framworks?

Because that's the word PMs and clients typically use when they are
describing a system, and BDD attempts to eliminate vocabulary
differences between the client and the programmer.

True, they sometimes say "must", when they really want to emphasize
something.  But for the most part they say things like "after the user
logs in they should be shown a list of overdue frobbits, if there are
any".
Daniel B. (Guest)
on 2008-11-19 21:47
(Received via mailing list)
On Nov 19, 11:50 am, "Avdi G." <removed_email_address@domain.invalid> wrote:
> [1]http://fit.c2.com/
> [2]http://github.com/aslakhellesoy/cucumber/wikis

Aha, thanks! I saw Brandon Keeper's talk[1] on Cucumber at the Great
Lakes Ruby Bash, so I should have remembered that.

Regards,

Dan

[1]
http://www.slideshare.net/bkeepers/behavior-driven...
David C. (Guest)
on 2008-11-19 22:12
(Received via mailing list)
On Tue, Nov 18, 2008 at 7:46 AM, Einar Magnús Boson
<removed_email_address@domain.invalid> wrote:
> don't know enough about BDD. Especially when you use tests to design
> interfaces the "should" thinking comes more natural: You don't have a
> feature yet but you write down what it should do, then you implement it.

This is definitely part of the motivation behind "should."

Keep in mind that BDD started off as an attempt to help TDD newbies to
understand TDD as a design/documentation practice. The word "should"
was chosen for a few reasons.

First, it was to get people who were writing test names like test_pop
to write test names like
test_pop_should_return_the_object_at_the_top_of_the_stack instead.
From this perspective, any such word (should, must, aughta, etc) would
do just fine.

The other motivation for should was in part what Einar suggests here.

If you're writing the test first, then the code doesn't do what it
should yet. So should makes sense in that moment (before the test
passes) to say "should."

Later, when a previously passing test fails, when it says "should'
then you get to ask "should it?" That failure *might* be because a
code change introduced a bug, or it could be that a new requirement
nullifies or somehow challenges a previous requirement.

FWIW,
David
Thomas S. (Guest)
on 2008-11-20 03:31
(Received via mailing list)
On Nov 19, 3:08 pm, "David C." <removed_email_address@domain.invalid> wrote:
> do just fine.
> nullifies or somehow challenges a previous requirement.
Thanks. This thread has been even more fruitful than I expected. I
truly understand why "should" has been used. Not to say "must" and
others are wrong, of course, but I see how the perspective of
anticipation of code-to-be lends to the use of word "should". It
occurs to me that "expect" is also a good word form this perspective;
and interestingly we see that term being used in both TDD and BDD.

Something else I noticed. Originally I wanted reuse the word "assert"
--I like the word. So instead of 'should' I defined a helper to do:

  e.assert == r

Now, with this new perspective, I figure I'd go ahead and use #should.
When I went to convert it however it didn't quite come out as I
expected, because I had put the expectation first and the actualized
result last. Ie.

  expected.should == result

While this is OK, it doesn't quite translate. It reads much better:

  result.should == expected

That's how we talk about these things.

But then it hits me, trying to make this read well has led to a
potential issue. In Ruby equality is tested by the receiver. If we
make result the receiver then it is the one deciding if it is equal to
the expected. But a robust implementation would have the expected
decide.

I realize this is small minutia to the overall issues involved, but I
thought it was an interesting point nonetheless. It would seem, the
way in which we speak and think about things cannot necessarily be
reflected in the way we write our code.

T.
This topic is locked and can not be replied to.