Re: [Pharo-dev] Which tests should be run in CI?
Torsten, For unit tests building on green builds might be enough, but what about integration/smoke tests? Concrete case: I added a test to check that no class implements >>packages That is a test that should be run by all builds, but is not. The consequence is that Moose and Pharo3 based builds using seaside or magritte can not reliably use "senders of" I assume there are more tests like this. Stephan
Hi Stephan, Thanks for pushing the #packages problem. The Moose jobs run the Moose-specific tests (those defined in the Tests group in the configuration). But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo? Cheers, Doru Cheers, Doru On Wed, Dec 11, 2013 at 9:36 PM, Stephan Eggermont <stephan@stack.nl> wrote:
Torsten,
For unit tests building on green builds might be enough, but what about integration/smoke tests?
Concrete case: I added a test to check that no class implements >>packages That is a test that should be run by all builds, but is not. The consequence is that Moose and Pharo3 based builds using seaside or magritte can not reliably use "senders of"
I assume there are more tests like this.
Stephan
-- www.tudorgirba.com "Every thing has its own flow"
On 12 Dec 2013, at 06:31, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Stephan,
Thanks for pushing the #packages problem.
But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo?
the test tests that there is no #packages in Pharo on the class side other than the one that returns the rpackage istance. â> this is the case, the test is green.
The Moose jobs run the Moose-specific tests (those defined in the Tests group in the configuration).
You are not running that test as you are only running the moose tests. Marcus
Hi, On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 12 Dec 2013, at 06:31, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Stephan,
Thanks for pushing the #packages problem.
But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo?
the test tests that there is no #packages in Pharo on the class side other than the one that returns the rpackage istance. â> this is the case, the test is green.
Oh, so the API classes were fixed. I should have checked before (I just did). Great.
The Moose jobs run the Moose-specific tests (those defined in the Tests group in the configuration).
You are not running that test as you are only running the moose tests.
I know. I just explained why the test does not fail in the moose job :). We need to reconsider how we approach continuous integration for pharo-based images. Doru
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
Hi, I meant to say that projects that use pharo should rethink the tests and rules they run in order to ensure that they do not break the Pharo constraints. For example, for Moose, we should have, like Stephan suggested, an integration job that runs all tests in the image (at least). Ideally, it should also run other rules that ensure that the system does not break due to semantic mismatches. If we do it this way, we push the signals upstream and discover the problems sooner. Cheers, Doru On Thu, Dec 12, 2013 at 8:16 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
We need to reconsider how we approach continuous integration for pharo-based images. can you expand ?
-- www.tudorgirba.com "Every thing has its own flow"
On 12 Dec 2013, at 08:14, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Dec 2013, at 06:31, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Stephan,
Thanks for pushing the #packages problem.
But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo?
the test tests that there is no #packages in Pharo on the class side other than the one that returns the rpackage istance. â> this is the case, the test is green.
Oh, so the API classes were fixed. I should have checked before (I just did). Great.
But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package. What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? What is itâs responsibility? wouldnât it be good enough to have a #gpackage method? In general, you should evaluate Grease and put all the *concepts* it adds into Pharo itself. This way even the Core system can use them and everything gets better. Marcus
+1 I do not really get it because we mentioned that several times. Grease maintainers should simply produce a new version and Seaside/users should use this new version.
But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package.
What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? What is itâs responsibility? wouldnât it be good enough to have a #gpackage method?
In general, you should evaluate Grease and put all the *concepts* it adds into Pharo itself. This way even the Core system can use them and everything gets better.
Marcus
This is clearly an issue of Grease. And it is not essential either as there are no senders to it. So, I see no reason not to rename it in Grease. Cheers, Doru On Thu, Dec 12, 2013 at 8:28 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
+1 I do not really get it because we mentioned that several times. Grease maintainers should simply produce a new version and Seaside/users should use this new version.
But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package.
What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? What is itâs responsibility? wouldnât it be good enough to have a #gpackage method?
In general, you should evaluate Grease and put all the *concepts* it adds into Pharo itself. This way even the Core system can use them and everything gets better.
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
On 12 Dec 2013, at 08:22, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Dec 2013, at 08:14, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Thu, Dec 12, 2013 at 7:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 12 Dec 2013, at 06:31, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Stephan,
Thanks for pushing the #packages problem.
But, it's strange that the Pharo3 build is not red. Could it be that the test was not integrated into Pharo?
the test tests that there is no #packages in Pharo on the class side other than the one that returns the rpackage istance. â> this is the case, the test is green.
Oh, so the API classes were fixed. I should have checked before (I just did). Great.
But *Grease* still is the problem: in the tradition of the wonderful philosophy âLets keep all smalltalk crappy and provide some layer on topâ, it redefines #package and therefore requires that no Smalltalk ever implements #packages on the class side to return the system concept of package.
What you need to find out: Why does Grease need a #package method? Is there a GreasePackage class? What is itâs responsibility? wouldnât it be good enough to have a #gpackage method?
Another idea: if there is #package in Grease, there should be a class GreasePackage (or Package?). Maybe the API of the class is actually good (grease apis tend to be good). So maybe that API makes sense to be provided by RPackage? The real question is: what is the implementation of #package in Grease, what does it return and what does that object do? Marcus
participants (4)
-
Marcus Denker -
Stephan Eggermont -
Stéphane Ducasse -
Tudor Girba