Why don't you just use #assert: and #=? This is much shorter and the description string is not really worth the troubles, isn't it :-) Lukas PS: Ok, I know, there is the error string. On 21 June 2011 22:45, Max Leske <maxleske@gmail.com> wrote:

+1

On 21.06.2011, at 19:16, Sean P. DeNigris wrote:

...

In my unit test, I want to make sure that my output equals the expectedOutput, but:    TestCase>>assert: expected equals: actual

It feels wrong to me. It seems that I want to make an assertion about my class's behavior and I would like to write:    self assert: output equals: expectedOutput.

What do you all think?

Thanks. Sean

-- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Lukas Renggli www.lukas-renggli.ch

Lukas Renggli wrote:

the description string is not really worth the troubles, isn't it :-)

When using Autotest, the error message is key because I can see what's going on and continue editing without having to do or inspect anything. Sean -- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615213.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

On Tue, Jun 21, 2011 at 10:32 PM, Bernardo Ezequiel Contreras < vonbecmann@gmail.com> wrote:

did you check this http://code.google.com/p/pharo/issues/detail?id=4129 ?

Yes, I was the gulty. But I am still on favor. So I don't undersatnd Sean's problem.

On Tue, Jun 21, 2011 at 2:16 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:

...

In my unit test, I want to make sure that my output equals the expectedOutput, but: TestCase>>assert: expected equals: actual

It feels wrong to me. It seems that I want to make an assertion about my class's behavior and I would like to write: self assert: output equals: expectedOutput.

What do you all think?

Thanks. Sean

-- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Mariano http://marianopeck.wordpress.com

Mariano Martinez Peck wrote:

I don't understand Sean's problem.

Still using 1.2.2 :) Thanks for fixing it. Sean -- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Why don't you use the Phexample tools, for me this feels much more natural and the error output is much more readable.. self assert: 1 = 2. becomes 1 should = 2. http://www.iam.unibe.ch/~akuhn/blog/2009/shoulda-use-this-in-pharo/ http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-exp... camillo On 2011-06-22, at 06:02, laurent laffont wrote:

IMO having the expected value before is the right way ! Do you TDD ? It makes a lot of sense for me to write assert: expected equals: actual. Am I alone ?

If you do TDD, you have first to decide what you expect. You don't know how to get it because the code doesn't exist yet. So you usually I write

self assert: 'i want this' equals:

then stop because I have to think about the interface / selectors / object I want. So it matches the flow of thought when I'm writing tests.

And the other weird thing is that with this "fix" I now have to change hundred of tests I've written to be semantically correct !!!!

Laurent.

On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Mariano Martinez Peck wrote:

...

I don't understand Sean's problem.

Still using 1.2.2 :) Thanks for fixing it.

Sean

-- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Camillo and Dennis, Thanks for answer and yes, I think you're right about using PhExample/Mocketry DSL, that's the way to go. Laurent. On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <chaetal@gmail.com> wrote:

2011/6/22 laurent laffont <laurent.laffont@gmail.com>

...

IMO having the expected value before is the right way ! Do you TDD ? It makes a lot of sense for me to write assert: expected equals: actual. Am I alone ?

I practice TDD, and I start tests with assertions (after naming them). But I'm not sure I specify expected value first, as I'm focused on the result (I write the test for). Btw, I use Mocketry and exploit its sugar (or DSL?) for specifications there. So, I write:

actualValue should equal: expectedValue.

That is, after I've decided on a test case and named it, I think: what should I test? That's the actualValue. I name and write it. And only after that, I think about the value it should have… well, in most cases at least.

Anyway, I'm not sure an order I use to write assertion should be repeated by assertion messages. Just as order I use to write a test (name -> assertion -> the way to fetch the actual value -> …) is not reflected by test code. It's much more important to have a readable and understandable (after many months) code. And for me it's much more natural to read it this way:

self assert: actualValue equals: expectedValue

If you do TDD, you have first to decide what you expect. You don't know how

...

to get it because the code doesn't exist yet. So you usually I write

self assert: 'i want this' equals:

then stop because I have to think about the interface / selectors / object I want. So it matches the flow of thought when I'm writing tests.

And the other weird thing is that with this "fix" I now have to change hundred of tests I've written to be semantically correct !!!!

Laurent.

On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris <sean@clipperadams.com

...

wrote:

...

Mariano Martinez Peck wrote:

...

I don't understand Sean's problem.

Still using 1.2.2 :) Thanks for fixing it.

Sean

-- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Dennis Schetinin

On Wed, Jun 22, 2011 at 7:58 AM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

On Jun 22, 2011, at 7:44 AM, laurent laffont wrote:

...

Camillo and Dennis,

Thanks for answer and yes, I think you're right about using PhExample/Mocketry DSL, that's the way to go.

except that I would not patch SUnit but have another Testing framework for that. And I\m not sure that I want to write should equals:..... not enought experience to have a good point of view

I don't know about PhExample but Mocketry does not patch SUnit but provide extensions to Object / SmallInteger / ... for the DSL part. It loads easily and also have an HelpSystem book :) Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMocketry'; load. ConfigurationOfMocketry load. 1 should equal: 1. I think I will use it for TWM. Laurent.

...

Laurent.

On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <chaetal@gmail.com> wrote:

2011/6/22 laurent laffont <laurent.laffont@gmail.com> IMO having the expected value before is the right way ! Do you TDD ? It makes a lot of sense for me to write assert: expected equals: actual. Am I alone ?

I practice TDD, and I start tests with assertions (after naming them). But I'm not sure I specify expected value first, as I'm focused on the result (I write the test for). Btw, I use Mocketry and exploit its sugar (or DSL?) for specifications there. So, I write:

actualValue should equal: expectedValue.

That is, after I've decided on a test case and named it, I think: what should I test? That's the actualValue. I name and write it. And only after that, I think about the value it should have… well, in most cases at least.

Anyway, I'm not sure an order I use to write assertion should be repeated by assertion messages. Just as order I use to write a test (name -> assertion -> the way to fetch the actual value -> …) is not reflected by test code. It's much more important to have a readable and understandable (after many months) code. And for me it's much more natural to read it this way:

self assert: actualValue equals: expectedValue

If you do TDD, you have first to decide what you expect. You don't know how to get it because the code doesn't exist yet. So you usually I write

self assert: 'i want this' equals:

then stop because I have to think about the interface / selectors / object I want. So it matches the flow of thought when I'm writing tests.

And the other weird thing is that with this "fix" I now have to change hundred of tests I've written to be semantically correct !!!!

Laurent.

On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris < sean@clipperadams.com> wrote:

Mariano Martinez Peck wrote:

...

I don't understand Sean's problem.

Still using 1.2.2 :) Thanks for fixing it.

Sean

-- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Dennis Schetinin

Hi, Phexample does not patch SUnit at all. It adds only Object>>should, and then everything else is 100% SUnit compatible by extending TestCase with Phexample. But beside the DSL, with Phexample you also get a new way of organizing your tests. Every test returns a value and thus becomes an example. And examples can be based on other examples. This simple change makes the setUp irrelevant because you can simply use an example for setting up. I believe this is a cool infrastructure. Cheers, Doru On 22 Jun 2011, at 08:38, laurent laffont wrote:

On Wed, Jun 22, 2011 at 7:58 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

On Jun 22, 2011, at 7:44 AM, laurent laffont wrote:

...

Camillo and Dennis,

Thanks for answer and yes, I think you're right about using PhExample/Mocketry DSL, that's the way to go.

except that I would not patch SUnit but have another Testing framework for that. And I\m not sure that I want to write should equals:..... not enought experience to have a good point of view

I don't know about PhExample but Mocketry does not patch SUnit but provide extensions to Object / SmallInteger / ... for the DSL part.

It loads easily and also have an HelpSystem book :)

Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfMocketry'; load.

ConfigurationOfMocketry load.

1 should equal: 1.

I think I will use it for TWM.

Laurent.

...

Laurent.

On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <chaetal@gmail.com> wrote:

2011/6/22 laurent laffont <laurent.laffont@gmail.com> IMO having the expected value before is the right way ! Do you TDD ? It makes a lot of sense for me to write assert: expected equals: actual. Am I alone ?

I practice TDD, and I start tests with assertions (after naming them). But I'm not sure I specify expected value first, as I'm focused on the result (I write the test for). Btw, I use Mocketry and exploit its sugar (or DSL?) for specifications there. So, I write:

actualValue should equal: expectedValue.

That is, after I've decided on a test case and named it, I think: what should I test? That's the actualValue. I name and write it. And only after that, I think about the value it should have… well, in most cases at least.

Anyway, I'm not sure an order I use to write assertion should be repeated by assertion messages. Just as order I use to write a test (name -> assertion -> the way to fetch the actual value -> …) is not reflected by test code. It's much more important to have a readable and understandable (after many months) code. And for me it's much more natural to read it this way:

self assert: actualValue equals: expectedValue

If you do TDD, you have first to decide what you expect. You don't know how to get it because the code doesn't exist yet. So you usually I write

self assert: 'i want this' equals:

then stop because I have to think about the interface / selectors / object I want. So it matches the flow of thought when I'm writing tests.

And the other weird thing is that with this "fix" I now have to change hundred of tests I've written to be semantically correct !!!!

Laurent.

On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Mariano Martinez Peck wrote:

...

I don't understand Sean's problem.

Still using 1.2.2 :) Thanks for fixing it.

Sean

-- View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

-- Dennis Schetinin

-- www.tudorgirba.com "Sometimes the best solution is not the best solution."

On Wed, Jun 22, 2011 at 4:38 PM, <csrabak@bol.com.br> wrote:

Maybe it's the timezone/jetlag but given "equals" is a commutative operation does this really matters® that much?

It only matters for the error message you get and the temporary variable names when you debug. Not a big deal. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry