#assert:equals: feels backwards
Locked
12
12
#assert:equals: feels backwards
 
Administrator
|
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
Cheers,
Sean |
|
|
+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. > |
Re: #assert:equals: feels backwards
|
|
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 <[hidden email]> 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 |
Re: #assert:equals: feels backwards
|
|
In reply to this post by Sean P. DeNigris
I remember a thread about this not long ago... Try searching the history :)
Guille On Tue, Jun 21, 2011 at 2:16 PM, Sean P. DeNigris <[hidden email]> wrote: In my unit test, I want to make sure that my output equals the |
Re: #assert:equals: feels backwards
|
|
In reply to this post by Lukas Renggli
that nobody never reads :-) I think in Smalltalk it does not make too much sense to have assert:equals:, like you say, it does not add value... but in those "parenthesis languages" were number are not objects and etc... well, they need it :-)
-- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina |
Re: #assert:equals: feels backwards
|
|
In reply to this post by Guillermo Polito
yes, there was. It is like that because that is how it is in JUnit.... everybody agreed it was rare and if I'm not wrong, was going to be changed
On Tue, Jun 21, 2011 at 4:56 PM, Guillermo Polito <[hidden email]> wrote: I remember a thread about this not long ago... Try searching the history :) -- Hernán Wilkinson
Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [hidden email] site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina |
Re: #assert:equals: feels backwards
|
|
In reply to this post by Sean P. DeNigris
On Tue, Jun 21, 2011 at 7:16 PM, Sean P. DeNigris <[hidden email]> wrote:
In my unit test, I want to make sure that my output equals the Personnally I prefer assert: expected equals: actual because the first thing I have to think about is what I expect, not how to get it. So for me it feels more natural to write it this way.
Laurent.
|
Re: #assert:equals: feels backwards
|
Administrator
|
In reply to this post by Lukas Renggli
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
Cheers,
Sean |
Re: #assert:equals: feels backwards
|
|
In reply to this post by Sean P. DeNigris
did you check this
http://code.google.com/p/pharo/issues/detail?id=4129 ? On Tue, Jun 21, 2011 at 2:16 PM, Sean P. DeNigris <[hidden email]> wrote: In my unit test, I want to make sure that my output equals the |
Re: #assert:equals: feels backwards
|
|
On Tue, Jun 21, 2011 at 10:32 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote: did you check this Yes, I was the gulty. But I am still on favor. So I don't undersatnd Sean's problem.
-- Mariano http://marianopeck.wordpress.com |
Re: #assert:equals: feels backwards
|
|
there's no problem. you (Mariano) fixed it.
i think you misunderstood Sean's mail. On Tue, Jun 21, 2011 at 6:05 PM, Mariano Martinez Peck <[hidden email]> wrote:
|
Re: #assert:equals: feels backwards
|
Administrator
|
In reply to this post by Mariano Martinez Peck
Still using 1.2.2 :) Thanks for fixing it. Sean
Cheers,
Sean |
Re: #assert:equals: feels backwards
|
|
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 <[hidden email]> wrote:
|
Re: #assert:equals: feels backwards
|
|
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-expand-on.html 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 <[hidden email]> 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. > > |
Re: #assert:equals: feels backwards
|
|
In reply to this post by laurent laffont
2011/6/22 laurent laffont <[hidden email]>
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:
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:
-- Dennis Schetinin |
Re: #assert:equals: feels backwards
|
|
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 <[hidden email]> wrote:
|
Re: #assert:equals: feels backwards
|
|
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 > > Laurent. > > > On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <[hidden email]> wrote: > > > 2011/6/22 laurent laffont <[hidden email]> > 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 <[hidden email]> 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 > |
Re: #assert:equals: feels backwards
|
|
On Wed, Jun 22, 2011 at 7:58 AM, Stéphane Ducasse <[hidden email]> wrote:
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.
|
Re: #assert:equals: feels backwards
|
|
In reply to this post by Lukas Renggli
On Tue, Jun 21, 2011 at 9:51 PM, Lukas Renggli <[hidden email]> wrote:
> 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 :-) When the test fails, you can debug more easily with #assert:equals:. If you use #assert: and #= you know that the boolean passed to #assert: is false, not really useful. If you use #assert:equals: you have the two objects and you can compare them. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
|
|
In reply to this post by Sean P. DeNigris
Maybe it's the timezone/jetlag but given "equals" is a commutative operation does this really matters® that much?
Will your unit tests behave incorrectly if you just code: self assert: actual equals: expected. ? my 0.0199999.... -- Cesar Rabak Em 21/06/2011 14:16, Sean P. DeNigris < [hidden email] > escreveu: 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. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |