This is really helpful, thanks for the resources everyone! On Thu, Mar 3, 2016 at 1:22 PM, Dan Smith <[email protected]> wrote:
> Hi Matt, > > For unit testing Functions and cache listeners, you basically just need to > want to mock the arguments. Mockito or jMock are good choices for creating > a mock FunctionContext or EntryEvent. You hopefully shouldn't need to use > PowerMock - if you run into a case where you think you need it, please file > a bug against geode API! > > One option to consider is whether you want to use spring data gemfire's > annotation support for functions. That can avoid the need to mock a > function context, because spring will automatically map the arguments to > the parameters of your method. > > > http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#function-annotations > > On Thu, Mar 3, 2016 at 8:56 AM, Matt Ross <[email protected]> wrote: > >> Ethan, >> >> The concept of what I'm trying to unit test is not what I'm asking >> about. I know it's not the developers job to unit test whether a cache >> listener properly fires. I'm saying let's say we have a cache listener that >> takes events and does a transformation on them. Or I have a function that >> returns to me the results of a specific Oql query. I'm asking how from a >> technical perspective am I able to write unit tests so that I could run >> them without bringing up a cluster. >> >> My ideal workflow involves being able to run these unit tests as part of >> my Jenkins CI pipeline. >> >> >> On Thursday, March 3, 2016, Eitan Suez <[email protected]> wrote: >> >>> hi matt, >>> >>> what helps me is to ask myself "what is it i want to test?" >>> >>> i should be confident, for example, that gemfire will call my >>> cachelistener on a cacheevent. so i shouldn't need to test that (at least >>> not at the unit level). but whether the code in the body of my >>> afterCreate() or afterUpdate() is doing what i expect it to is my >>> responsibility: that's what i need to unit test. so technically you >>> shouldn't have to bring in the gemfire machinery to unit-test a >>> cachelistener. >>> >>> now if the body of that method interacts with regions (for example), >>> you'll want to mock that interaction. >>> >>> integration or functional testing is more involved: you have to stand >>> up an instance of gemfire with the configuration that will install your >>> cache listeners or functions, and have to setup some trigger that will >>> exercise the function you're testing, and then be able to verify the >>> outcome. >>> >>> / eitan >>> >>> >>> On Thu, Mar 3, 2016 at 9:06 AM, Matt Ross <[email protected]> wrote: >>> >>>> Hi all >>>> >>>> A colleague and I have been talking about the best strategies to do >>>> unit testing and TDD in Gemfire/Geode. Obviously writing unit tests for a >>>> Gemfire/Geode Client is fairly straightforward, but how would I unit test a >>>> function that I'm running on the cluster. Or how would I write tests for a >>>> cache listener? I've been pointed in the direction of power mock but could >>>> still use some more input from the community on what some of the better >>>> strategies are. >>>> >>>> Are there any examples on Github of how to write these serverside unit >>>> tests? Like I said at this point we're only able to do integration testing >>>> and unit testing of the client so I've been fairly limited in being able to >>>> do TDD. Thanks! >>>> >>>> -- >>>> *Matthew Ross | Data Engineer | Pivotal* >>>> *625 Avenue of the Americas NY, NY 10011* >>>> *516-941-7535 <516-941-7535> | [email protected] * >>>> >>>> >>> >> >> -- >> *Matthew Ross | Data Engineer | Pivotal* >> *625 Avenue of the Americas NY, NY 10011* >> *516-941-7535 <516-941-7535> | [email protected] <[email protected]> * >> >> >> > -- *Matthew Ross | Data Engineer | Pivotal* *625 Avenue of the Americas NY, NY 10011* *516-941-7535 <516-941-7535> | [email protected] <[email protected]> *
