Comments on: Latching and mocking in concurrent tests http://blog.xebia.com/2009/11/03/latching-and-mocking-in-concurrent-tests/ Thu, 11 Mar 2010 16:23:01 +0100 http://wordpress.org/?v=2.8.4 hourly 1 By: Iwein Fuld http://blog.xebia.com/2009/11/03/latching-and-mocking-in-concurrent-tests/comment-page-1/#comment-93046 Iwein Fuld Thu, 12 Nov 2009 12:11:39 +0000 http://blog.xebia.com/?p=3359#comment-93046 I'm not a mock fanboy, but neither am I allergic to them like Uncle Bob. Byteman seems like a very interesting tool to test the concurrent nature of your program, whereas my trick merely allows you to deal with concurrency in a functional test. I'd say usually a trick like this is enough, but if you're chasing after concurrency bugs it pays off to look a little further. I’m not a mock fanboy, but neither am I allergic to them like Uncle Bob.

Byteman seems like a very interesting tool to test the concurrent nature of your program, whereas my trick merely allows you to deal with concurrency in a functional test. I’d say usually a trick like this is enough, but if you’re chasing after concurrency bugs it pays off to look a little further.

]]> By: Andrew Dinn http://blog.xebia.com/2009/11/03/latching-and-mocking-in-concurrent-tests/comment-page-1/#comment-93023 Andrew Dinn Thu, 05 Nov 2009 09:18:12 +0000 http://blog.xebia.com/?p=3359#comment-93023 You might also take a look at <a>Byteman</a>, a bytecode injection tool which was developed to address testing of multi-threaded apps. It makes this sort of thing trivial to achieve and avoids the need for mocking. Take a look at my paper in this year's <a HREF="http://jazoon.com/en/conference/presentations/tl/7460" rel="nofollow">Jazoon</a> for an example of how to inject a synchronization point into a multi-threaded program, thereby exposing a concurrency bug. It requires a few lines of Byteman rule code and, more importantly, no edits to the original program. Countdowns are also provided as standard built-in operations. They can be used in Byteman conditions to decide whether or not to execute injected actions. Combined with a rendezvous action this can be used to ensure that threads synch up at the NTH call. You might also take a look at Byteman, a bytecode injection tool which was developed to address testing of multi-threaded apps. It makes this sort of thing trivial to achieve and avoids the need for mocking.

Take a look at my paper in this year’s Jazoon for an example of how to inject a synchronization point into a multi-threaded program, thereby exposing a concurrency bug. It requires a few lines of Byteman rule code and, more importantly, no edits to the original program. Countdowns are also provided as standard built-in operations. They can be used in Byteman conditions to decide whether or not to execute injected actions. Combined with a rendezvous action this can be used to ensure that threads synch up at the NTH call.

]]> By: Andrew Phillips http://blog.xebia.com/2009/11/03/latching-and-mocking-in-concurrent-tests/comment-page-1/#comment-93011 Andrew Phillips Tue, 03 Nov 2009 22:31:42 +0000 http://blog.xebia.com/?p=3359#comment-93011 Another interesting - if somewhat old - option for concurrent testing is <a href="http://www.cs.umd.edu/projects/PL/multithreadedtc/overview.html" target="_new" rel="nofollow">Multithreaded TC</a>; there have also been some recent efforts to <a href="http://code.google.com/p/multithreadedtc-junit4/" target="_new" rel="nofollow">integrate it</a> with JUnit 4. That said, I haven't found a nice way to get it to do what your example does - provide a latch or delay <em>within</em> the flow of the code under test (in your example, in a mock). MTC is great in coordinating test threads but otherwise assumes that the code under test "naturally" blocks, e.g. when doing a take from a blocking queue. Another interesting – if somewhat old – option for concurrent testing is Multithreaded TC; there have also been some recent efforts to integrate it with JUnit 4.
That said, I haven’t found a nice way to get it to do what your example does – provide a latch or delay within the flow of the code under test (in your example, in a mock). MTC is great in coordinating test threads but otherwise assumes that the code under test “naturally” blocks, e.g. when doing a take from a blocking queue.

]]> By: David http://blog.xebia.com/2009/11/03/latching-and-mocking-in-concurrent-tests/comment-page-1/#comment-93010 David Tue, 03 Nov 2009 20:16:48 +0000 http://blog.xebia.com/?p=3359#comment-93010 Latches are definitely useful in many situations. May I point you to a, in my opinion, related blog entry by Uncle Bob: http://blog.objectmentor.com/articles/2009/10/28/manual-mocking-resisting-the-invasion-of-dots-and-parentheses Personally I tend to lean toward using mocks, but I don't think there's any right way. As always, it's about using the right tool for the right job. Latches are definitely useful in many situations. May I point you to a, in my opinion, related blog entry by Uncle Bob: http://blog.objectmentor.com/articles/2009/10/28/manual-mocking-resisting-the-invasion-of-dots-and-parentheses
Personally I tend to lean toward using mocks, but I don’t think there’s any right way. As always, it’s about using the right tool for the right job.

]]>