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 Demarey <christophe.demarey@inria.fr> 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 some Nautilus methods). I would like that Pharo detects tes methods all methods of a class subclassing (directly or not) TestCase AND starting with either 'test' or 'should'. I also would like to add 'deny' to not use 'shouldNot' but here I'm not sure.

WDYT?

Christophe.

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 conflicting concepts of what a test selector is in Core. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-and-BDD-tp4820612p4820673.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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 CompiledMethod>>#isTestMethod, so now we already have two conflicting concepts of what a test selector is in Core.

In fact, I already did the changes in an image (but not published, I wait for feedback) and I also noticed the duplicated logic. Monty also pointed me to take care of this problem: https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-t.... What I did is really simple: In TestCase Class, add update #testSelectors and #methodChanged: to use #isTestSelector: update shouldInheritSelectors to fix a wrong behavior In ClassTestCase, update selectorsTested to use #isTestSelector: Update Nautilus extension method CompiledMethod>>isTestMethod to use TestCase>>#isTestSelector: I will add a slice for that but I'm not sure if it is a good idea to include tests beginning with deny.

Le 21 avr. 2015 à 11:38, Esteban Lorenzano a écrit :

...

On 21 Apr 2015, at 10:22, Christophe Demarey <Christophe.Demarey@inria.fr> 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 duplicated quite a bit. And someone even snuck your proposed change into CompiledMethod>>#isTestMethod, so now we already have two conflicting concepts of what a test selector is in Core.

In fact, I already did the changes in an image (but not published, I wait for feedback) and I also noticed the duplicated logic. Monty also pointed me to take care of this problem: https://pharo.fogbugz.com/f/cases/12280/Nautilus-treats-should-messages-as-t....

What I did is really simple: In TestCase Class, add <Capture d’écran 2015-04-21 à 10.12.36.png>

hi, side note: take into account that the use of #or: as you are using it is not recommended. Better something like:

firstTerm or: [ secondTerm or: [ thirdTerm or [ etc. ] ] ]

yes, is uglier, but faster :)

ok ;)

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 (fine-grain, white-box approach) that made the functionalities. So, the tooling in BDD should be different of the tooling used in TDD (BDD is more high-level than TDD).

In BDD each functionalities are describes as :

As a <role> I want <some feature> So that <I gain a benefit>

And the functionality is described in different scenarios (nominal and error ones) : Given <some initial context> When <an event occurs> Then <ensure some outcomes>

Basic example:

As a customer, I want to withdraw cash from an ATM, so that I don’t have to wait in line at the bank.

Scenario 1: Account is in credit Given the account is in credit And the card is valid And the dispenser contains cash When the customer requests cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned

In fact, a useful and good BDD tool must provide : a way to define a set of initial data a DSL to define the functionalities and for each of them to express the scenarios according to the schema above an engine that feeds automatically the scenario from the data set and that outputs the result. Miguel Moquillon

yes, you're right on all these points. I'm not aware of such a library for Pharo but it would be very nice. On top of that, you could add a dashboard collecting automatically these tests (that are more or less User Stories) to show your customer which user stories are completed. 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 that may leads people to test the implementation details and not the expected behavior.

Le 21 avr. 2015 à 10:44, Sven Van Caekenberghe a écrit :

...

On 21 Apr 2015, at 10:36, Christophe Demarey <Christophe.Demarey@inria.fr> 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 that may leads people to test the implementation details and not the expected behavior.

Not that your naming ideas are bad, but right now you can write

testAccountShouldBePositiveAfterEachOperation

which is not that bad

I agree. I do not want to push things that won't be used. That's why I did not yet proposed a slice. Maybe I will just let it as it is now and just propose to include the refactoring to have the logic of the test selection in one place. With Guille, we discussed a bit around tests and came to the conclusion that it would be good to have a blog post or a book chapter on test solutions and how to test the good thing. We have, for example: SUnit BabyMock (http://smalltalkhub.com/#!/~zeroflag/BabyMock2) Mocketry (http://smalltalkhub.com/#!/~dionisiy/Mocketry) PhExample (http://smalltalkhub.com/#!/~PharoExtras/Phexample) BoTest (http://smalltalkhub.com/#!/~CAR/BoTest) Kiwi TDD (https://www.youtube.com/watch?v=m2t_MbVAdis) and maybe others. Thanks for the feedback.

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 in our image) became incomprehensible from a "how do I use this library" POV, tested internal implementation details, etc. So BDD was invented to make the focus on behaviors explicit and to guide us all toward best practice. It also quite nicely unified acceptance testing and unit testing. The "In order to..." that you're describing is the outer, high-level acceptance test that in Ruby for example might be written with Cucumber. But once one has a failing acceptance test, the next step in BDD is to drop down into e.g. RSpec and write something a lot closer to a unit test, often mocking out collaborators to drive creation of an API. In summary, the intent of BDD is to be "TDD Done Right". There is no inherent conflict, and no specific tools are technically required. Although, since as McLuhan suggested, we become our tools, so obviously the proper tools may be decisive, especially when first learning. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-and-BDD-tp4820612p4820803.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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 order to..." that you're describing is the outer, high-level acceptance test that in Ruby for example might be written with Cucumber. But once one has a failing acceptance test, the next step in BDD is to drop down into e.g. RSpec and write something a lot closer to a unit test, often mocking out collaborators to drive creation of an API.

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. The word 'Test' in TDD doesn't mean its purpose is to test; it is a misconception. In fact TDD is a method for developers to focus on the design of their code by avoiding over-designing. In other side, BDD stands for test, more exactly functional testing. It is a safety belt to avoid both functional regressions and to ensure the written code is valid according to the requirements.

So, when a functional test failed, the next step in BDD is to pass the control to the developer to fix the issue whatever its method (BDD don't cover this level). They are not related but, as you wrote in your example with Ruby, they can be used both in a project, at a different level. BDD doesn't imply TDD but yes, in practice, they are often used in conjunction. Now, some tools were inspired by BDD to provide the developers a better way to express unit tests (RSpec for example), to be more focused on the design, but they are in fact more related to TDD than BDD. Don't confound the approach with the tools.

There is no inherent conflict, and no specific tools are technically required. Although, since as McLuhan suggested, we become our tools, so obviously the proper tools may be decisive, especially when first learning. There is no conflicts between TDD and BDD because they are not related and they are not concurrent. In fact they can be used both but at different level. The same with the tools. Beside that, I have a principle: don't learn an approach through a tool. But use a tool to facilitate the application of the approach. And as you wrote, indeed, the proper tool is important.

Miguel Moquillon

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 to have a separate package. I ckecked and we already diverged a lot from the SUnit standard (use of Traits, announcements, etc.). Do you want I integrate the refactoring to have the test selectors selection coherent? If yes, my proposal just adds 'or: [ selector name beginsWith: 'should' ]. I do not see the point of having a separate package. If no, does it mean that we should never touch the SUnit package?

No this is just that for now we do not express dependencies to a Sunit package number :) but when we will start to do it, it may be more complex. I got some problems with SUnit and SUnitToo in VW. Not fun.