Using thread pools in a Spock Spy'd class hangs during unit tests

[Kevin Dorff]

Hi,

I tried to search Google (and here) for others reporting this or a similar problem but had no obvious success.

I am attempting to write Spock unit tests for a class which contains a method that use a thread pool to do work. I have tried GPars withPool and Java's Executor fixed-size pool. It seems that if I Spy the class when that class tries to do work with a thread pool, the unit test hangs.

I have created a simple example and set of simple Spock test cases which demonstrate what I am seeing. In my repo, the failing test cases are marked as @Ignore because they will, for me, reliably hang the test suite.

https://github.com/kdorff/SpiesAndGpars

All use

• Using Groovy 2.4.7
  
• Java (1.7.0_80 or 1.8.0_92)
  

The CalcSpec class uses:

• Spock-core 1.1-groovy-2.4-rc-3.
  
• CGLib 3.2.4

Any opinions, suggestions, or thoughts are welcome. I initially asked this of the GPars people, but they suggested that the issue must be with the Spied class somehow not being compatible with the thread pool. This sparked me to add a method (and tests) that uses the Java Executor's pools. But these appear to exhibit the same issue.

Thanks,

Kevin

[Alexander Kriegisch]

Hi Kevin.

Your first two ignored tests do not need a Spy, they run fine with a normal Calc object.

As for the other two tests, I do not understand what you are trying to test. And why do you need a Spy anyway (Spy is usually bad and a sign that you should refactor your code)? To me those two tests do not really make sense. If I knew why you think you absolutely need a Spy there, maybe I would think about what goes wrong there. To me it just looks like you want to see what you can do with a Spy anyway instead of a test which makes any logical sense.

Regards
--
Alexander Kriegisch
https://scrum-master.de

--
You received this message because you are subscribed to the Google Groups "Spock Framework - User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spockframewor...@googlegroups.com.
To post to this group, send email to spockfr...@googlegroups.com.
Visit this group at https://groups.google.com/group/spockframework.
For more options, visit https://groups.google.com/d/optout.

[Alexander Kriegisch]

Hi Kevin.

Your first two ignored tests do not need a Spy, they run fine with a normal Calc object.

As for the other two tests, I do not understand what you are trying to test. And why do you need a Spy anyway (Spy is usually bad and a sign that you should refactor your code)? To me those two tests do not really make sense. If I knew why you think you absolutely need a Spy there, maybe I would think about what goes wrong there. To me it just looks like you want to see what you can do with a Spy anyway instead of a test which makes any logical sense.

Regards
--
Alexander Kriegisch
https://scrum-master.de

[Kevin Dorff]

Hi,

What I have presented is a (hopefully) easy bit of code to understand which demonstrates the problem. This is not the actual production code, which is property of my company and if I posted that I'd have to answer SO MANY more questions. This simple code should be consumable by anyone and clearly demonstrates the issue I am having. Yes, perhaps i can refactor my code such that I don't have to use Spy or can spy a class that doesn't contain a thread pool which might fix it. That said...

The purpose for my first failing test is to demonstrates that (two kinds of) thread pools hang because of something about the Spy (not the Spy plus any method mocking). The tests all exist to exercise the Calc.groovy code in some way. The failing tests do the same things as the non-failing tests do, but use one of two different thread pools. In both cases, using the thread pool within a Spied object hangs the execution. Which is why I am asking.

Kevin

[Alexander Kriegisch]

Well, Kevin,

all I can tell you is that a Spy is a CGLIB dynamic proxy class with all its features and limitations. For more in-depth infos I leave it to others with more expertise to answer. But in the meantime why don't you just use a good old anonymous subclass? ;-)

void "gpars: Test with calc as spy, add a 2x number and a list of 2x numbers (parallel)"() {
  setup:
  calc = new Calc() {
    @Override
    Integer add(Integer n) {
      return super.add(n * 2)
    }
  }

  expect:
  calc.add(3) == 6
  calc.addListParallelGpars([-5, 4, 8]) == 20
}

This works nicely. Call it your home-grown spy if you like. I guess this should unblock you until you come up with a solution you like better. But I think this is simple and readable, so why not use it for good?

Regards

--

Alexander Kriegisch

https://scrum-master.de

[Kevin Dorff]

Thank you for the information and suggestions.

Kevin