expect

[Alex Chaffee]

I was showing Wrong to Sarah Allen yesterday and she mentioned something that I've personally experienced too, and might impede Wrong adoption. 

Briefly: 

* Human brains (at least those raised speaking a Romance language) tend to want to say "I expect A (actual) to equal X (expected)". 

* Kent Beck is clearly a Martian since he put "expected" first ("assertEquals(X, A)"); 

* RSpec got it right since you say A.should == X, and this at least in part helps explain its popularity.

* It's helpful to have a convention so you instinctively know which order the parameters are in, at least for simple 2-part predicates.

* Wrong is ambiguous since it's order-agnostic, and this can lead to a bit of friction (confusion, delay, flow-breakage) in writing or understanding tests. 

* Any amount of mental friction is bad.

* Jasmine and ScrewUnit use "expect", and I expect (ahem) other BDD frameworks do too. This makes assertions slot nicely in to the verbal template "I expect A (actual) to equal X (expected)".

So, I'd like to propose making "expect" be a standard alias for "assert" in Wrong. Users can already make this happen themselves with "Wrong.config.alias_assert :expect" but if it's built in, and if it's in the docs and examples, then people might soak it in more.

Any furious objections? Or other thoughts?

--
Alex Chaffee - al...@stinky.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch | http://alexch.tumblr.com

[Alex Chaffee]

On Sat, Nov 6, 2010 at 11:20 AM, Alex Chaffee <al...@stinky.com> wrote:

So, I'd like to propose making "expect" be a standard alias for "assert" in Wrong. Users can already make this happen themselves with "Wrong.config.alias_assert :expect" but if it's built in, and if it's in the docs and examples, then people might soak it in more.

Oh yeah, also it fits in with the failure message:

    expect { current_user == "joe" } # => Expected (current_user == "joe") but current_user is "fred"

is more natural than

    assert { current_user == "joe" } # => Expected (current_user == "joe") but current_user is "fred"

[Steve Conover]

It's not just about an alias though, it's about confusion in
communication. We have to decide that there are two sizeable target
audiences we want to communicate with and that it's worth taking on
the communication problems in order to satisfy those two audiences.

Right now there is zero ambiguity or guesswork necessary to
communicate with of humans about what wrong does. There are two
things, I would like to assert that they are equal to each other.
It's a proposition, but stronger than that, it walks right up to "I'm
*certain* I'm correct" but allows for wrongness.

So what are you going to put in your slides? Are you going to say
that wrong is an assertion framework, or that it's an expect
framework? If you say the latter, do you expect anyone to understand
what it is you're saying?

This feels to me like another button on the iPod. But the I'm
consistently in favor of being brutally minimal in APIs...

[Alex Chaffee]

On Sat, Nov 6, 2010 at 6:59 PM, Steve Conover <scon...@gmail.com> wrote:

It's not just about an alias though, it's about confusion in
communication.  We have to decide that there are two sizeable target
audiences we want to communicate with and that it's worth taking on
the communication problems in order to satisfy those two audiences.

Yeah, I think that captures it well. CS vs. BDD. The former is more venerable and theoretical and correct; the latter is about making "tests" and "assertions" conform to a more commonplace and less threatening mindset and lexicon.

In parody, it's pompous vs. squishy.

 

Right now there is zero ambiguity or guesswork necessary to
communicate with of humans about what wrong does.  There are two
things, I would like to assert that they are equal to each other.
It's a proposition, but stronger than that, it walks right up to "I'm
*certain* I'm correct" but allows for wrongness.

You mean this as an argument in favor of "assert" but after I read it I thought, yeah, you know, "assert" actually is a bit too arrogant for the occasion; "expect" is a more humble and realistic expression of what an assertion is trying to convey. "I assert" in math and science is not arrogant, but in common language it's pretty aggressive, and doesn't admit of uncertainty. "Expect", however, does convey uncertainty -- you're sticking your neck out but if you're wrong, it's cause for curiosity, not shame.

This connotation of "expect" also supports the maxim "Good tests fail."

Another point Sarah raised (or really the same point) is "nobody knows what 'assert' means", which is technically false, but hyperbolically makes the case for squishier language.

In this analysis, it's just another plank in the "WTB new testing terminology" platform.

["WTB" = Want To Buy, a common cry in MMORPG chatrooms]

So what are you going to put in your slides?  Are you going to say
that wrong is an assertion framework, or that it's an expect
framework?  If you say the latter, do you expect anyone to understand
what it is you're saying?

Good question. Maybe. Maybe the right name for the library is Expect. "Have you seen Expect?" 

(Except there's already a project with that name, which is like Cucumber for .NET. http://expect.codeplex.com/)

 

This feels to me like another button on the iPod.  But the I'm
consistently in favor of being brutally minimal in APIs...

Documentation and slides aside, maybe I'll make the alias be part of the more-than-minimal API that you get when saying "require 'wrong'" rather than the minimal API of "require 'wrong/assert'" that you prefer. 

 

On Sat, Nov 6, 2010 at 11:28 AM, Alex Chaffee <al...@stinky.com> wrote:
>
>
> On Sat, Nov 6, 2010 at 11:20 AM, Alex Chaffee <al...@stinky.com> wrote:
>>
>> So, I'd like to propose making "expect" be a standard alias for "assert"
>> in Wrong. Users can already make this happen themselves with
>> "Wrong.config.alias_assert :expect" but if it's built in, and if it's in the
>> docs and examples, then people might soak it in more.
>
> Oh yeah, also it fits in with the failure message:
>     expect { current_user == "joe" } # => Expected (current_user == "joe")
> but current_user is "fred"
> is more natural than
>     assert { current_user == "joe" } # => Expected (current_user == "joe")
> but current_user is "fred"
>

 

[Steve Conover]

> Yeah, I think that captures it well. CS vs. BDD. The former is more
> venerable and theoretical and correct; the latter is about making "tests"
> and "assertions" conform to a more commonplace and less threatening mindset
> and lexicon.
> In parody, it's pompous vs. squishy.

That's fine and makes sense. I agree these audiences are distinct and
sizeable, the question is whether benefit outweighs cost, which is a
guess.

> You mean this as an argument in favor of "assert" but after I read it I
> thought, yeah, you know, "assert" actually is a bit too arrogant for the
> occasion; "expect" is a more humble and realistic expression of what an
> assertion is trying to convey.

I think you could come down on either side, depends on
nuances/subtleties that are important to you.

> "I assert" in math and science is not
> arrogant, but in common language it's pretty aggressive, and doesn't admit
> of uncertainty. "Expect", however, does convey uncertainty -- you're
> sticking your neck out but if you're wrong, it's cause for curiosity, not
> shame.

Agreed. There's something attractive on another front too:
experimentation. You "expect" outcomes. It's the layman version of
"I hypothesize that x== y"

> This connotation of "expect" also supports the maxim "Good tests fail."
> Another point Sarah raised (or really the same point) is "nobody knows what
> 'assert' means", which is technically false, but hyperbolically makes the
> case for squishier language.

Who's "no one" (this is not a challenge, I'm certain there are groups
of people who tend not to be familiar with 'assert'. That doesn't
include agile/TDD types, design by contract types, most C programmers
or other languages with an assert keyword)? Does she have beginners
in mind?

> Good question. Maybe. Maybe the right name for the library is Expect. "Have
> you seen Expect?"
> (Except there's already a project with that name, which is like Cucumber for
> .NET. http://expect.codeplex.com/)

And it's a well-known automation tool:
http://en.wikipedia.org/wiki/Expect

I don't see any reason why a library named Wrong ought not have a
major method named expect.

> Documentation and slides aside, maybe I'll make the alias be part of the
> more-than-minimal API that you get when saying "require 'wrong'" rather than
> the minimal API of "require 'wrong/assert'" that you prefer.

Not bad. So I could do

require "wrong/assert"
require "wrong/expect"

...and get the alias?

[Phlip]

> * Kent Beck is clearly a Martian since he put "expected" first
> ("assertEquals(X, A)");

That's partly because KB (and his heritage in Smalltalk) use "Yoda
statements". Actually "yiddish statements"...

"Strong" == the_dark_side

...and partly because, when assertEquals() fails, it prints a
diagnostic that ass-u-me-s the left value is the reference and the
right is the sample.

A correctly written diagnostic should not assume either type of value
(or even that the statement failed).

> * Wrong is ambiguous since it's order-agnostic, and this can lead to a bit
> of friction (confusion, delay, flow-breakage) in writing or understanding
> tests.

Wrong. The lack of a mechanical mistake in the diagnostic should not
be used as an excuse to enforce a rule. Teams should like to enforce
rules, and their favorite order should emerge and then be maintained.

> * Jasmine and ScrewUnit use "expect", and I expect (ahem) other BDD
> frameworks do too. This makes assertions slot nicely in to the verbal
> template "I expect A (actual) to equal X (expected)".

The goal of BDD is natural language. IOW...

the_goal_of_BDD.should == 'natural language'

Halfway there! Speakers of European languages naturally say "sample is
reference".

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

[Phlip]

> That's partly because KB (and his heritage in Smalltalk) use "Yoda
> statements". Actually "yiddish statements"...
>
>   "Strong" == the_dark_side

"Yoda Conditions".

C-:

[Alex Chaffee]

On Sun, Nov 7, 2010 at 11:32 AM, Steve Conover <scon...@gmail.com> wrote:

> Documentation and slides aside, maybe I'll make the alias be part of the
> more-than-minimal API that you get when saying "require 'wrong'" rather than
> the minimal API of "require 'wrong/assert'" that you prefer.

Not bad.  So I could do

require "wrong/assert"
require "wrong/expect"

...and get the alias?

Sure!

But (continuing a different argument), I see no benefit, and some disadvantages, of the require form relative to 

require "wrong/assert"

Wrong.config.alias_assert :expect

especially given that the content of expect.rb will just be that line of code.

[Steve Conover]

If you considered requiring the canonical way of layering on features,
then it makes sense, and the fact that there is only one line of code
is either neither here nor there or something to be celebrated.

If you're going to do this then obviously do whatever you think is
best, I'm just laying out the argument in favor.