On 19 Feb 2013, at 7:59, Adrian Kuhn ak...@iam.unibe.ch wrote:
On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote:
That gives rise to example-driven testing ala:
Foo #barShouldBeSomething
So far, I tried to avoid that, and make examples that are really focused on
one specific subject,
On 19 February 2013 07:59, Adrian Kuhn ak...@iam.unibe.ch wrote:
On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote:
That gives rise to example-driven testing ala:
Foo #barShouldBeSomething
So far, I tried to avoid that, and make examples that are really focused on
one specific subject,
Great post... a lot to think about :)
Adrian Kuhn wrote
Classes and methods are not the best model to structure tests. Alas in
Smalltalk it's all we can work with we cannot break free from classes
and methods (imposed by the Smalltalk IDE rather than the language) so its
what we must
While wondering how to simply support Pharo 1.4 and Pharo 2.0 at the same time,
I noticed something I didn't think about before.
Phexample does use the following code to identify what a test method is:
each numArgs isZero and:
[ (each asLowercase includesSubString:
On Feb 10, 2013, at 9:39 PM, Stefan Marr smallt...@stefan-marr.de wrote:
While wondering how to simply support Pharo 1.4 and Pharo 2.0 at the same
time, I noticed something I didn't think about before.
Phexample does use the following code to identify what a test method is:
each
This is great. I love the matchers in Phexample (although I'm not sold on the
test dependency part. I think dependent tests should be skipped, not
failed... yet I digress...)
Stefan Marr-3 wrote
Note that it is #includesSubString, in contrast to #beginsWith:.
Is that on purpose?
This means
