Added: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPhexample'; load. (Smalltalk at: #ConfigurationOfPhexample) load. Actually one test is failing in PharoCore 1.3: ForExampleStack>>shouldFailWhenPopEmpty Laurent. On Thu, Jun 23, 2011 at 10:18 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
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."