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. |
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:
-- 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. |
On Thu, Mar 31, 2016 at 5:20 PM, Dale Henrichs <[hidden email]> wrote:
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...
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. |
On 03/31/2016 03:05 PM, Mariano
Martinez Peck wrote:
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. |
Free forum by Nabble | Edit this page |