On Apr 6, 2012, at 1:19 PM, Guillermo Polito wrote: > > > On Fri, Apr 6, 2012 at 1:12 PM, Benjamin > <[email protected]> wrote: > > On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote: > >> >> On Thu, Apr 5, 2012 at 3:17 PM, Benjamin >> <[email protected]> wrote: >> per instance ? >> I you wanna know when a test instance you run started, I think there are >> better solutions than announcement. >> >> Hehe, actually, if you are the one firing the test, then you do need nothing >> :). Also the tests instances are discarded to have independent state so >> what I said is nonsense :). >> >> >> For me the goal of announcement is to emit, and than everyone can catch this >> information. >> >> Hmm, that's one specific use for them... You can build for example a small >> application using announcements to decouple the UI from the model, and there >> you probably will not make the announcer accessible for everyone. > > It's not specific, I think it should be the default behavior. > > Because if you want to listen only the FooTestClass announcement, you can > always record yourself as a listener for all TestAnnouncement, and then test > if the announcement is relevant for you or not. > > > Because if you need to know which class emit the announcement to be able to > register, then you create a strong dependency from your class to the test > class. And this is wrong (and announcement have been introduced to break this > pattern) > > But that way you are creating a strong dependency against another class like > TestAnnouncement or just TestCase :P. And if you want to filter the > announcements for a specific class, you will do it too!
You create a dependency to the Announcer instead of the classes emitting announcement, I think this is the correct way to do it :) Of course if you filter you create a dependency to the test class. But you only create a strong dependency in the case you are really interested by this particular class. If you want to listen to every test classes, you do not have to create a strong dependency to all the classes Ben > Anyway, if you're metaprogramming, then for sure are other ways to get the > class without having a static reference to it. > > > > > Ben > > >>> On Thu, Apr 5, 2012 at 2:57 PM, Benjamin >>> <[email protected]> wrote: >>> Since there is an announcer per test class, you need to write something like >>> >>> MyClass>>#register >>> MyTestClass announcer >>> on: TestCaseStarted send: #foo to: self. >>> >>> It means than here you force a link from MyClass to MyTestClass. >>> And if you want to be aware of all test case started, you need something >>> like >>> >>> TestCase withAllSubclasses do: [:e | e announcer >>> on: >>> TestCaseStarted send: #foo to: self ]. >>> >>> Why not using only one Announcer (and TestAnnouncer already exists and is >>> already integrated) for all test class ? >>> >> >> And then you lack the possibility to subscribe to a specific one... Maybe >> you can add a method in TestCase hiding the subscriptions to all the >> subclasses. >> >>> >>> Ben >>> >>> >>> On Apr 5, 2012, at 3:50 PM, Alexandre Bergel wrote: >>> >>> > I proposed this test announcement facilities some times ago to get >>> > notified when tests are being executed and when they are done. >>> > >>> > You said: "It means that you have to know which class to register to >>> > instead of which announcer." >>> > Which unit to register you mean? Yes, the one you are interested in. I do >>> > not see why it break the pattern. Consider >>> > TestCaseTest>>testAnnouncement. What is wrong with it? >>> > >>> > Cheers, >>> > Alexandre >>> > >>> > >>> > On 5 Apr 2012, at 06:14, Benjamin wrote: >>> > >>> >> Hello guys, >>> >> >>> >> I was implementing in Nautilus a listener to TestCaseStarted, and then I >>> >> figured out that each TestCase subclasses have its own Announcer. >>> >> >>> >> It means that you have to know which class to register to instead of >>> >> which announcer. In a way, it breaks the Observer pattern. >>> >> >>> >> Is there any good reason I am missing ? >>> >> >>> >> I think it has been done in a way you can spy a particular test class, >>> >> but since you have this info in the announcement itself, you can always >>> >> filter with this info. >>> >> Cause for me, replacing all those announcer by TestAnnouncer seems to be >>> >> a better solution. >>> >> >>> >> >>> >> >>> >> Thanks in advance, >>> >> >>> >> Ben >>> > >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >>> >> >> > >
