Re: ConfigurationOfPhexample (was #assert:equals: feels backwards)

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 <[hidden email]> 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 <[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
> >
>
>
>

--
www.tudorgirba.com

"Sometimes the best solution is not the best solution."