0

I need to stub Java.util.concurrent.Executors class newFixedThreadPool method and verify it.

    Executors.newFixedThreadPool(executorServiceThreadCount, threadFactory)

I tried create a global Executors value for overriding from test fragment. 

    lazy val executors = Executors

But newFixedThreadPool method is not reachable from executors instance. What should i do for stubbing this method. And any best practise for this ? Thanks

user3816201
  • 78
  • 7
  • Short answer: you can't. Static methods are global and defined once and for all, you cannot override them. You could try defining a new trait that would forward to `Executors`'s methods and use that in all your code. Then you could "stub" that trait. – Régis Jean-Gilles Mar 10 '16 at 13:44

2 Answers2

1

You can use PowerMockito to mock static methods. Use the following annotations on top of your test class:

@RunWith(PowerMockRunner.class) @PrepareForTest({Executors.class, ClassYouAreTesting.class})

and use the following code to mock the newFixedThreadPool method:

PowerMockito.mockStatic(Executors.class); Mockito.when(Executors.newFixedThreadPool(5)).thenReturn(mockService);

Sarneet Kaur
  • 2,860
  • 1
  • 14
  • 12
0

The newFixedThreadPool method is probably already tested so I wouldn't spend much time trying to test it.

Instead I would assume what you're actually trying to do is test a class that uses the newFixedThreadPool return type (ExecutorService). If that is the case then you have several options:

  1. Use dependency injection and create an integration test style - What you can do is pass an ExecutorService to your class under test (you can do so using either a constructor or a setter. I usually pass it to the constructor but this is a totally different topic) and then pass an ExecutorService mock. I gotta say that in the past I tried mocking the ExecutorService code and it was not very fun. The advantage of this approach is that you can also test the interactions between your threads and so test a scenario which better reflects the real scenario.
  2. A more unit test approach will be to test the code that gets invoked by the threads in your thread pool (the callable/runnable code you're about to run). This is much easier to write and definitely more isolated. The downside here is that you're not testing all the interactions between your threads.

A few things I should probably add:

  • I tend not to favor all these power tools that allow you to do some magic tricks (such as mocking static methods etc), not because they're not powerful enough but its just feels that if you need so much power to just test something then there might be something wrong with your design
  • I intentionally avoided some hot topics like setter/constructor injection and integration/unit tests since I felt like its out of scope
  • I usually try and avoid (if possible) having shared resources between my threads so I don't gain much from taking the more integration style approach (in these scenarios)

I hope this helps :)

Gideon
  • 2,211
  • 5
  • 29
  • 47