Le 24/4/15 12:26, Christophe Demarey a écrit :
Le 22 avr. 2015 à 20:19, stepharo a écrit :
Christophe
I do not have the answer just the constraints.
This is hyper important that the solution does not change much SUnit.
This way we do not end up with a mess with Sunit version.
It is better t
Le 22 avr. 2015 à 20:19, stepharo a écrit :
> Christophe
>
> I do not have the answer just the constraints.
> This is hyper important that the solution does not change much SUnit.
> This way we do not end up with a mess with Sunit version.
>
> It is better to have a separate package.
I ckecked
Christophe
I do not have the answer just the constraints.
This is hyper important that the solution does not change much SUnit.
This way we do not end up with a mess with Sunit version.
It is better to have a separate package.
Stef
Le 20/4/15 13:02, Christophe Demarey a écrit :
Hi,
With BDD
Miguel Moquillon wrote
>> In summary, the intent of BDD is to be "TDD Done Right".
> I don't agreed with your assumption: there is a difference
> philosophically both in theory and in practice.
In actuality, it is a bit overstated, because one key insight of BDD was to
bring /all/ stakeholders in
Le 21/04/2015 13:44, Sean P. DeNigris a écrit :
Miguel Moquillon wrote
BDD and TDD stands for different purposes with different actors...
While that's unfortunately often true in practice, there is no difference
philosophically. [T|B]DD "done right" always focuses on the user.
[...]
The "In ord
Le 21 avr. 2015 à 13:44, Sean P. DeNigris a écrit :
> Miguel Moquillon wrote
>> BDD and TDD stands for different purposes with different actors...
>
> While that's unfortunately often true in practice, there is no difference
> philosophically. [T|B]DD "done right" always focuses on the user. But
Miguel Moquillon wrote
> BDD and TDD stands for different purposes with different actors...
While that's unfortunately often true in practice, there is no difference
philosophically. [T|B]DD "done right" always focuses on the user. But
because of the word "test" in TDD, many tests (including many
Le 21 avr. 2015 à 11:38, Esteban Lorenzano a écrit :
>
>> On 21 Apr 2015, at 10:22, Christophe Demarey
>> wrote:
>>
>>
>> Le 20 avr. 2015 à 18:23, Sean P. DeNigris a écrit :
>>
>>> Sean P. DeNigris wrote
refactor so that all those places use one implementation somewhere.
>>>
>>> In fa
Le 21 avr. 2015 à 10:44, Sven Van Caekenberghe a écrit :
>
>> On 21 Apr 2015, at 10:36, Christophe Demarey
>> wrote:
>>
>> To come back to my proposition, it is just a first step to BDD to not
>> prevent people to define tests with something like
>> shouldAccountBalanceBePositiveAfterEachOp
> On 21 Apr 2015, at 10:22, Christophe Demarey
> wrote:
>
>
> Le 20 avr. 2015 à 18:23, Sean P. DeNigris a écrit :
>
>> Sean P. DeNigris wrote
>>> refactor so that all those places use one implementation somewhere.
>>
>> In fact, searching the sources for "beginsWith: 'test'", the logic is
>>
On 21/04/15 10:14, Miguel Moquillon wrote:
In BDD each functionalities are describes as :
As a
I want
So that
And the functionality is described in different scenarios (nominal and
error ones) :
Given
When
Then
This can be mapped rather easily on a subclass of TestCase, even the
variant
> On 21 Apr 2015, at 10:36, Christophe Demarey
> wrote:
>
> To come back to my proposition, it is just a first step to BDD to not prevent
> people to define tests with something like
> shouldAccountBalanceBePositiveAfterEachOperation (more behavior driven)
> rather than testMyWonderfulMethod
Hi,
Le 21 avr. 2015 à 10:14, Miguel Moquillon a écrit :
> Hi,
>
> BDD and TDD stands for different purposes with different actors.
> In BDD, stakeholders work on the functionalities of software units (coarse
> grain, black-box approach) whereas on TDD developers work on the object's
> features
Le 20 avr. 2015 à 18:23, Sean P. DeNigris a écrit :
> Sean P. DeNigris wrote
>> refactor so that all those places use one implementation somewhere.
>
> In fact, searching the sources for "beginsWith: 'test'", the logic is
> duplicated quite a bit. And someone even snuck your proposed change into
Hi,
BDD and TDD stands for different purposes with different actors.
In BDD, stakeholders work on the functionalities of software units
(coarse grain, black-box approach) whereas on TDD developers work on the
object's features (fine-grain, white-box approach) that made the
functionalities. So,
refactor so that all those places use one implementation somewhere.
In fact, searching the sources for "beginsWith: 'test'", the logic is
duplicated quite a bit.
So we should refactor it.
And someone even snuck your proposed change into
CompiledMethod>>#isTestMethod, so now we already have t
demarey wrote
> as it is something that is not specific to a project, I would prefer to
> have it in the system.
I agree that would be nice. I much prefer #shouldXyz. At the same time I
don't mind so much having to override #testSelectors, and if we make this
change, we must be ready for people to
Sean P. DeNigris wrote
> refactor so that all those places use one implementation somewhere.
In fact, searching the sources for "beginsWith: 'test'", the logic is
duplicated quite a bit. And someone even snuck your proposed change into
CompiledMethod>>#isTestMethod, so now we already have two conf
Yes, I could but as it is something that is not specific to a project, I would
prefer to have it in the system.
Le 20 avr. 2015 à 12:47, Sven Van Caekenberghe a écrit :
> You could override TestCase class>>#testSelectors in your own subclass, no ?
>
>> On 20 Apr 2015, at 12:02, Christophe Demar
You could override TestCase class>>#testSelectors in your own subclass, no ?
> On 20 Apr 2015, at 12:02, Christophe Demarey
> wrote:
>
> Hi,
>
> With BDD a current test practice is to start method names with 'should'.
> It is not yet possible in Pharo but easily do-able (update of TestCase and
Hi,
With BDD a current test practice is to start method names with 'should'.
It is not yet possible in Pharo but easily do-able (update of TestCase and some
Nautilus methods).
I would like that Pharo detects tes methods all methods of a class subclassing
(directly or not) TestCase AND starting w
21 matches
Mail list logo
