1 Mar 2009 12:35
Re: Thoughts on jMock and multithreading?
I'm a bit undecided on this one. So far, we've had a very opinionated story, which is that JMock doesn't do multithreading. If you want to test threaded code, then there are other ways to do that, especially now that Hamcrest is shaping up. One of our strong claims is that jmock will help you write the "right" kind of code because it pushes you into the appropriate corners, for example that threaded code should minimise its synchronisation points. I fear that we'll lose the message if we make it too easy -- that's why mocking classes is an extension and not built-in. An alternative to implementing support for threads is to complain when they're found, which would solve the confusing failures problem. S. On 28 Feb 2009, at 17:13, Nat Pryce wrote: > There's some debate going on among the jMock developers and the users > they know about whether jMock should support testing multithreaded > code. > > On one side, at the moment jMock forces you to separate the functional > behaviour of a unit from larger scale concurrency policies, so that > you can test the unit with the DeterministicExecutor or > DeterministicScheduler. > > On the other side, lots of Java code is multithreaded and plenty of > people use jMock in multithreaded tests and get wierd errors as a > result. >(Continue reading)
RSS Feed