Comments on: The End of Endotesting? http://dannorth.net/2008/09/the-end-of-endotesting It's all behaviour Sat, 06 Mar 2010 15:23:03 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Willed vs Forced designs at Mark Needham http://dannorth.net/2008/09/the-end-of-endotesting/comment-page-1#comment-24826 Willed vs Forced designs at Mark Needham Mon, 08 Feb 2010 22:49:04 +0000 http://dannorth.net/?p=69#comment-24826 [...] a couple of years ago with respect to whether using Mockito instead of jMock was bad because it hides design problems that you have with dependencies. Steve Freeman wrote the following comment on Dan's post: But, it also became clear that he wrote [...] [...] a couple of years ago with respect to whether using Mockito instead of jMock was bad because it hides design problems that you have with dependencies. Steve Freeman wrote the following comment on Dan's post: But, it also became clear that he wrote [...]

]]> By: David Starr's Blog http://dannorth.net/2008/09/the-end-of-endotesting/comment-page-1#comment-21392 David Starr's Blog Fri, 13 Feb 2009 18:52:13 +0000 http://dannorth.net/?p=69#comment-21392 Assertion Driven Design (ADD)... In all cases of using a unit test framework, no matter the intent of the test methods, one thing is certainly... Assertion Driven Design (ADD)...

In all cases of using a unit test framework, no matter the intent of the test methods, one thing is certainly…

]]> By: I wish there was a mocking framework… « monkey island http://dannorth.net/2008/09/the-end-of-endotesting/comment-page-1#comment-19042 I wish there was a mocking framework… « monkey island Mon, 03 Nov 2008 23:52:38 +0000 http://dannorth.net/?p=69#comment-19042 [...] reply to few interesting blog articles. Dan North became a friend of Mockito and wrote about the end of endotesting. His post sparked few interesting comments. Steve Freeman wrote: But, it also became clear that he [...] [...] reply to few interesting blog articles. Dan North became a friend of Mockito and wrote about the end of endotesting. His post sparked few interesting comments. Steve Freeman wrote: But, it also became clear that he [...]

]]> By: Keith Braithwaite http://dannorth.net/2008/09/the-end-of-endotesting/comment-page-1#comment-17525 Keith Braithwaite Thu, 25 Sep 2008 19:12:31 +0000 http://dannorth.net/?p=69#comment-17525 "I’ve been finding that novices and advanced beginners “get” mocking more quickly with Mockito than with the expectation-based alternatives." How are you distinguishing "get mocking" form "gain fluency with the tool"? “I’ve been finding that novices and advanced beginners “get” mocking more quickly with Mockito than with the expectation-based alternatives.”

How are you distinguishing “get mocking” form “gain fluency with the tool”?

]]> By: Dan North http://dannorth.net/2008/09/the-end-of-endotesting/comment-page-1#comment-17524 Dan North Thu, 25 Sep 2008 15:27:44 +0000 http://dannorth.net/?p=69#comment-17524 Hi Steve. I agree with using JMock as a teaching tool - I've had lots of success with it over the years. And I can't understate the impact it's had in terms of the wider adoption of mocking, as well as the secondary effects of its matcher library (@assertThat@ and hamcrest). I'm interested in how adopting Mockito would "address some weak design and coding habits". Is it about working around them so you can get work done _in spite of_ the bad habits, or does it provide a more gradual and intuitive path away from them (than expectation-based mocking)? An experienced TDDer will usually be equally fluent/expressive/focused using any decent mocking library, but I've been finding that novices and advanced beginners "get" mocking more quickly with Mockito than with the expectation-based alternatives. My sample group has been small so it may just be these people in this context. I haven't been using it for long enough - or across enough different contexts - to have decent empirical evidence yet. Hi Steve.

I agree with using JMock as a teaching tool – I’ve had lots of success with it over the years. And I can’t understate the impact it’s had in terms of the wider adoption of mocking, as well as the secondary effects of its matcher library (assertThat and hamcrest).

I’m interested in how adopting Mockito would “address some weak design and coding habits”. Is it about working around them so you can get work done in spite of the bad habits, or does it provide a more gradual and intuitive path away from them (than expectation-based mocking)?

An experienced TDDer will usually be equally fluent/expressive/focused using any decent mocking library, but I’ve been finding that novices and advanced beginners “get” mocking more quickly with Mockito than with the expectation-based alternatives. My sample group has been small so it may just be these people in this context. I haven’t been using it for long enough – or across enough different contexts – to have decent empirical evidence yet.

]]>