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]> * > > >
