NOTE: Re-sharing with the Apache Geode User List for everyone's benefit. Guy's original message:
> "*Hi john,* *>* *> We are using geode server and our clients are using remote function calls in order to call it.* *> Is STDG going to support also remote function calls as mock?* *> * *> Thanks,* *> Guy*" Hi Guy- First, I'd like to clarify that STDG is for both Unit and Integration Testing Apache Geode in a Spring context, and is not simply just for writing Unit Tests with Mock Objects (using *Mockito*). Just want to make that clear for anyone else reading this thread. Having said that, STDG in conjunction with SDG's Function (annotation) support [1], already sets the developer up nicely for mocking and writing Unit Tests for either Function implementations [2] or Function Executions [3]. See here for the difference between Function implementation and execution [4]. This is because SDG uses POJO methods for implementation and an interface definition for execution. Therefore, it is a simple matter to Unit Test either implementations and/or executions used by a Spring application, particularly for Executions [5] since the execution definition is simply an interface in SDG, unlike Apache Geode's API, which uses static methods on the FunctionService class [6] to execute Functions making it more difficult to mock and Unit Test effectively. All of this is to say there is really isn't anything additionally required in STDG in particular, or SDG in general, that needs to be done to make it possible to Mock and Unit Test Apache Geode Functions, whether that be implementations or executions. However, that is not to say we couldn't do more to facilitate this development task, but it is already quite easy, IMO. What I wanted to highlight for *Mario* was, especially looking at this from an "Integration Test" perspective (which is a valid arrangement for also testing your Function implementations/executions in much the same way that you would Integration Test that your SQL, or OQL in Geode's case, is well-formed), is that STDG contains Integration Test support (simply by extending the IntegrationTestsSupport class) to ensure that Apache Geode's state is properly cleaned up between test classes (not to be confused with... "between test in a test class/suite"). I hope this helps clarify STDG's position on this matter. Regards, John [1] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-annotations [2] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-implementation [3] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-execution [4] https://docs.spring.io/spring-data/geode/docs/current/reference/html/# [5] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/Execution.html [6] https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionService.html On Tue, Feb 11, 2020 at 12:04 PM John Blum <jb...@pivotal.io> wrote: > Hi Guy- > > First, I'd like to clarify that STDG is for both Unit and > Integration Testing Apache Geode in a Spring context, and is not simply > just for writing Unit Tests with Mock Objects (using Mockito). Just want > to make that clear for anyone else reading this thread. > > Having said that, STDG in conjunction with SDG's Function (annotation) > support [1], already sets the developer up nicely for mocking and > writing Unit Tests for either Function implementations [2] or Function > Executions [3]. See here for the difference between Function > implementation and execution [4]. > > This is because SDG uses POJO methods for implementation and an interface > definition for execution. Therefore, it is a simple matter to Unit Test > either implementations and/or executions used by a Spring application, > particularly for Executions [5] since the execution definition is simply > an interface in SDG, unlike Apache Geode's API, which uses static methods > on the FunctionService class [6] to execute Functions making it more > difficult to mock and Unit Test effectively. > > All of this is to say there is really isn't anything additionally required > in STDG in particular, or SDG in general, that needs to be done to make it > possible to Mock and Unit Test Apache Geode Functions, whether that be > implementations or executions. However, that is not to say we couldn't do > more to facilitate this development task, but it is already quite easy, IMO. > > What I wanted to highlight for *Mario* was, especially looking at this > from an "Integration Test" perspective (which is a valid arrangement for > also testing your Function implementations/executions in much the same > way that you would Integration Test that your SQL, or OQL in Geode's case, > is well-formed), is that STDG contains Integration Test support (simply by > extending the IntegrationTestsSupport class) to ensure that Apache > Geode's state is properly cleaned up between test classes (not to be > confused with... "between test in a test class/suite"). > > I hope this helps clarify STDG's position on this matter. > > Regards, > John > > [1] > https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-annotations > [2] > https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-implementation > [3] > https://docs.spring.io/spring-data/geode/docs/current/reference/html/#function-execution > [4] https://docs.spring.io/spring-data/geode/docs/current/reference/html/# > [5] > https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/Execution.html > [6] > https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/FunctionService.html > > > On Fri, Feb 7, 2020 at 11:11 PM Guy Turkenits <guy.turken...@amdocs.com> > wrote: > >> Hi john, >> >> We are using geode server and our clients are using remote function calls >> in order to call it. >> >> Is STDG going to support also remote function calls as mock? >> >> Thanks, >> >> Guy >> >> Sent from Nine >> ------------------------------ >> *From:* John Blum <jb...@pivotal.io> >> *Sent:* יום שישי, 7 בפברואר 2020 21:19 >> *To:* user@geode.apache.org >> *Subject:* Re: ClientCache didn't close properly >> >> These sort of problems are the exact types of things that *Spring Test >> for Apache Geode* (STDG) [1] was designed to handle. I experienced >> similar problems while testing features in the SDG, SSDG and SBDG projects, >> which is how STDG came to be. >> >> However, since you are not using *Spring* in this case, there are a few >> things you should be aware of. >> >> 1. ClientCache.close() does NOT guarantee that the [client] cache >> instance has been fully stopped and that all resources are properly >> released in a timely manner. >> 2. Depending on your version of Geode, the SSL state is maintained in >> static references that can linger without proper cleanup, especially in and >> between automated tests, and particularly if you are not forking new JVMs >> per test. >> 3. You should be careful how you set Geode properties (e.g. as Java >> System properties). Your approach (i.e. using the API) should be generally >> fine, however, keep in mind #1 above! >> 4. etc... >> >> There are other things to be aware of as well, but I simply wanted to >> list a few here for your reference. >> >> You can use this setup/tear down logic [2] from STDG as a guide in your >> own test scaffolding. You can safely ignore the *Spring*-specific tear >> down logic. >> >> As 1 example of testing SSL, you can review the SBDG test suite, >> beginning here [3]. SBDG offers support [4] to auto-configure SSL for >> Apache Geode, depending on your configuration. As you can imagine, SBDG's >> test suite is very comprehensive (given the auto-configuration for many >> Geode features), and because I don't like forking JVMs, it is imperative >> that each test properly cleanup after itself in a reliable manner >> especially if 1 tests uses SSL and the rest don't. Anyway... >> >> Hope this helps (give you ideas/pointers/etc)! >> >> Regards, >> -j >> >> >> [1] https://github.com/spring-projects/spring-test-data-geode >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fspring-2Dprojects-252Fspring-2Dtest-2Ddata-2Dgeode-26data-3D02-257C01-257CGuy.Turkenits-2540Amdocs.com-257C507b1d8800054cc464cf08d7ac02b661-257Cc8eca3ca127646d59d9da0f2a028920f-257C0-257C0-257C637166999976990205-26sdata-3Dlsb7d9jGosIXVJfrDkisC2c3iG1kn54C9-252FwHWFmVEIE-253D-26reserved-3D0&d=DwMF_Q&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=fQ_QMlhH-KZeo9O7jPfIHA&m=DZXzSsXKUSasapRsvBPS1pz3KVxWusyhKUWYzONCPlI&s=A1AS2M-7wTuU6ygWiHGjg7BX455u_Fr0OQYoNzm2fCw&e=> >> [2] >> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L106-L250 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fspring-2Dprojects-252Fspring-2Dtest-2Ddata-2Dgeode-252Fblob-252Fmaster-252Fspring-2Ddata-2Dgeode-2Dtest-252Fsrc-252Fmain-252Fjava-252Forg-252Fspringframework-252Fdata-252Fgemfire-252Ftests-252Fintegration-252FIntegrationTestsSupport.java-2523L106-2DL250-26data-3D02-257C01-257CGuy.Turkenits-2540Amdocs.com-257C507b1d8800054cc464cf08d7ac02b661-257Cc8eca3ca127646d59d9da0f2a028920f-257C0-257C0-257C637166999977000199-26sdata-3DQQlwnPmaeig09tq-252F-252FSyr-252BHkU3inSWtTHz1ibtoAXARs-253D-26reserved-3D0&d=DwMF_Q&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=fQ_QMlhH-KZeo9O7jPfIHA&m=DZXzSsXKUSasapRsvBPS1pz3KVxWusyhKUWYzONCPlI&s=djsVGe-0KBFiUWLaqO-TQeYJ8Qjka6Ax2UCuwt-rq30&e=> >> [3] >> https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-autoconfigure/src/test/java/org/springframework/geode/boot/autoconfigure/security/ssl/AutoConfiguredSslIntegrationTests.java >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fspring-2Dprojects-252Fspring-2Dboot-2Ddata-2Dgeode-252Fblob-252Fmaster-252Fspring-2Dgeode-2Dautoconfigure-252Fsrc-252Ftest-252Fjava-252Forg-252Fspringframework-252Fgeode-252Fboot-252Fautoconfigure-252Fsecurity-252Fssl-252FAutoConfiguredSslIntegrationTests.java-26data-3D02-257C01-257CGuy.Turkenits-2540Amdocs.com-257C507b1d8800054cc464cf08d7ac02b661-257Cc8eca3ca127646d59d9da0f2a028920f-257C0-257C0-257C637166999977000199-26sdata-3DOGLfKJdfTludfE6KQNg757NdJEpBv3Lfttxb7Z5eaqg-253D-26reserved-3D0&d=DwMF_Q&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=fQ_QMlhH-KZeo9O7jPfIHA&m=DZXzSsXKUSasapRsvBPS1pz3KVxWusyhKUWYzONCPlI&s=OjFFDqQ9AWem5--YmnVSKTaQgGtULBiG_u_TaouuYZQ&e=> >> [4] >> https://docs.spring.io/spring-boot-data-geode-build/1.3.x/reference/html5/#geode-security-ssl >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__eur01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdocs.spring.io-252Fspring-2Dboot-2Ddata-2Dgeode-2Dbuild-252F1.3.x-252Freference-252Fhtml5-252F-2523geode-2Dsecurity-2Dssl-26data-3D02-257C01-257CGuy.Turkenits-2540Amdocs.com-257C507b1d8800054cc464cf08d7ac02b661-257Cc8eca3ca127646d59d9da0f2a028920f-257C0-257C0-257C637166999977010191-26sdata-3DL8xUMz3gytvo96qlTxA1WNcgrWZUczQv0tHVYIqbsJY-253D-26reserved-3D0&d=DwMF_Q&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=fQ_QMlhH-KZeo9O7jPfIHA&m=DZXzSsXKUSasapRsvBPS1pz3KVxWusyhKUWYzONCPlI&s=qHB3dTp29OadYODeW1_HLBwOvgY6UJD0UsbapbWe20w&e=> >> >> >> On Fri, Feb 7, 2020 at 5:17 AM Mario Kevo <mario.k...@est.tech> wrote: >> >>> Hi all, >>> >>> We are using java client to test some functionality and it seems that we >>> have a problem with the client cache. >>> We started locator and server with SSL enabled. >>> On the client side also add SSL parameters, create proxy region, put >>> some entries and it works. >>> >>> Properties props = new Properties(); >>> >>> props.setProperty("ssl-enabled-components", "all"); >>> >>> props.setProperty("ssl-keystore", keystorePath); >>> >>> ... >>> >>> ClientCache clientCache = new >>> ClientCacheFactory(props).addPoolLocator("localhost", 10334) >>> .set("log-level", "info").create(); >>> >>> ... >>> clientCache.close(); >>> >>> After that we start another test with some other properties. >>> >>> As we are connecting from non-SSL-enabled client to SSL-enabled locator >>> we should get an exception, but didn't. >>> >>> >>> Properties props = new Properties(); >>> >>> props.setProperty("log-file", "test.log"); // no ssll parameters >>> >>> ... >>> >>> ClientCache clientCache = new >>> ClientCacheFactory(props).addPoolLocator("localhost", 10334) >>> >>> .set("log-level", "info").create(); >>> >>> ... >>> clientCache.close(); >>> >>> Despite of that we have in logs that *GemFire Properties defined with >>> api * has only this property changed but it somehow take also the cache >>> from the test before. >>> >>> The same thing happened if we change order of tests execution. >>> >>> >>> >>> Does anyone know is there a possibility that cache is saved somewhere >>> and if yes how to delete it? >>> >>> How to avoid this issue? >>> >>> >>> BR, >>> >>> Mario >>> >>> >> >> -- >> -John >> Spring Data Team >> >> *This email and the information contained herein is proprietary and >> confidential and subject to the Amdocs Email Terms of Service, which you >> may review at* *https://www.amdocs.com/about/email-terms-of-service* >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Dterms-2Dof-2Dservice&d=DwMFaQ&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=fQ_QMlhH-KZeo9O7jPfIHA&m=DZXzSsXKUSasapRsvBPS1pz3KVxWusyhKUWYzONCPlI&s=q8wMd0hNLmGx4W3ysr9FY9S8h27EyhTpPIO7vsNEhG4&e=> >> > > > -- > -John > Spring Data Team > -- -John Spring Data Team
