[Pharo-project] SUnit and TestCase
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 ? 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Why not using one announcer per instance test instance? That way you are only coupled to test runs you and only you fire. On Thu, Apr 5, 2012 at 2:57 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> 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 ?
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
per instance ? I you wanna know when a test instance you run started, I think there are better solutions than announcement. For me the goal of announcement is to emit, and than everyone can catch this information. Ben On Apr 5, 2012, at 3:03 PM, Guillermo Polito wrote:
Why not using one announcer per instance test instance? That way you are only coupled to test runs you and only you fire.
On Thu, Apr 5, 2012 at 2:57 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 ?
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Thu, Apr 5, 2012 at 3:17 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> 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.
On Thu, Apr 5, 2012 at 2:57 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote:
On Thu, Apr 5, 2012 at 3:17 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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) Ben
On Thu, Apr 5, 2012 at 2:57 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Fri, Apr 6, 2012 at 1:12 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> wrote:
On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote:
On Thu, Apr 5, 2012 at 3:17 PM, Benjamin < benjamin.vanryseghem.pharo@gmail.com> 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! 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 <
benjamin.vanryseghem.pharo@gmail.com> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Apr 6, 2012, at 1:19 PM, Guillermo Polito wrote:
On Fri, Apr 6, 2012 at 1:12 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
On Apr 5, 2012, at 3:37 PM, Guillermo Polito wrote:
On Thu, Apr 5, 2012 at 3:17 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 <benjamin.vanryseghem.pharo@gmail.com> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (3)
-
Alexandre Bergel -
Benjamin -
Guillermo Polito