[tode_st] Can I delete #testSigAbortHandlingNew

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[tode_st] Can I delete #testSigAbortHandlingNew

Mariano Martinez Peck
Dale,

#testSigAbortHandlingNew is the only guy that needs  'GemStone-GCI-Server-Tests' to be loaded in the server. I am not sure if this test covers functionallity of general GemStone-GCI or if it is Turgik related. If the later, then I would like to remove this test and the dependency of 'GemStone-GCI-Server-Tests' in the server.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] Can I delete #testSigAbortHandlingNew

Dale Henrichs-3
the testSigAbortHandlingNew _is_ moslty Tugrik-related, but it does have the benefit of testing the code for acquiring a server-side object and sending it messages ... not sure if that is covered elsewhere ...

I think it also makes the test for SigAbort Handling a bit simpler on the client-side, since the preferred way of using the GCI is to send messages to objects on the server rather than gen up a bunch of strings on the client and execute them:)

Having both is definitely redundant ...

Dale

On 03/31/2016 01:04 PM, Mariano Martinez Peck wrote:
Dale,

#testSigAbortHandlingNew is the only guy that needs  'GemStone-GCI-Server-Tests' to be loaded in the server. I am not sure if this test covers functionallity of general GemStone-GCI or if it is Turgik related. If the later, then I would like to remove this test and the dependency of 'GemStone-GCI-Server-Tests' in the server.

Thanks, 

--
--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] Can I delete #testSigAbortHandlingNew

Mariano Martinez Peck


On Thu, Mar 31, 2016 at 5:20 PM, Dale Henrichs <[hidden email]> wrote:
the testSigAbortHandlingNew _is_ moslty Tugrik-related, but it does have the benefit of testing the code for acquiring a server-side object and sending it messages ... not sure if that is covered elsewhere ...

Can we test that ( acquiring a server-side object and sending it messages) with a well known object and a well known message that we know that exist in all gemstones? That way we avoid having to load extra code in the stone.... and simplifies testing, CI, etc...
 

I think it also makes the test for SigAbort Handling a bit simpler on the client-side, since the preferred way of using the GCI is to send messages to objects on the server rather than gen up a bunch of strings on the client and execute them:)

Having both is definitely redundant ...

Dale


On 03/31/2016 01:04 PM, Mariano Martinez Peck wrote:
Dale,

#testSigAbortHandlingNew is the only guy that needs  'GemStone-GCI-Server-Tests' to be loaded in the server. I am not sure if this test covers functionallity of general GemStone-GCI or if it is Turgik related. If the later, then I would like to remove this test and the dependency of 'GemStone-GCI-Server-Tests' in the server.

Thanks, 

--
--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.



--

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [tode_st] Can I delete #testSigAbortHandlingNew

Dale Henrichs-3


On 03/31/2016 03:05 PM, Mariano Martinez Peck wrote:


On Thu, Mar 31, 2016 at 5:20 PM, Dale Henrichs <[hidden email]> wrote:
the testSigAbortHandlingNew _is_ moslty Tugrik-related, but it does have the benefit of testing the code for acquiring a server-side object and sending it messages ... not sure if that is covered elsewhere ...

Can we test that ( acquiring a server-side object and sending it messages) with a well known object and a well known message that we know that exist in all gemstones? That way we avoid having to load extra code in the stone.... and simplifies testing, CI, etc...
 
Well in this case we _can_ simplify things, but in terms of the SmalltalkCI support I cannot ignore a case where both the GemStone server and the Pharo client need to have code loaded before running tests (basically all of the projects that I listed earlier), but I would like to leave that test around until I get the SmalltalkCI/GsDevKit_home support completed.

At the point that I get SmalltalkCI support completed, testing, CI, travis, etc, should be simple (just define a .travis.yml and .smalltalk.ston file and you are set to go --- for both local stone creation, local client creation and travis builds --- at least that is my plan

Dale

--
You received this message because you are subscribed to the Google Groups "tODE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.