Comments on: Mock Frameworks, not for everyone and everytime http://blog.petermolgaard.com/2008/06/15/mock-frameworks-not-for-everyone-and-everytime/ Idealism is what precedes experience; cynicism is what follows... Sat, 20 Mar 2010 23:53:42 +0000 http://wordpress.com/ hourly 1 By: Peter Andreas Molgaard http://blog.petermolgaard.com/2008/06/15/mock-frameworks-not-for-everyone-and-everytime/#comment-1304 Peter Andreas Molgaard Tue, 30 Jun 2009 10:44:09 +0000 http://dopenhagen.wordpress.com/2008/06/15/mock-frameworks-not-for-everyone-and-everytime/#comment-1304 Hi Kris, Thanks for your input, now the post is more than a year old, so I realize that a lot of things have changed. Perhaps its time for me to revisit the topic and write more about it... // Peter Hi Kris,

Thanks for your input, now the post is more than a year old, so I realize that a lot of things have changed. Perhaps its time for me to revisit the topic and write more about it…

// Peter

]]> By: Kris http://blog.petermolgaard.com/2008/06/15/mock-frameworks-not-for-everyone-and-everytime/#comment-1303 Kris Tue, 30 Jun 2009 09:18:13 +0000 http://dopenhagen.wordpress.com/2008/06/15/mock-frameworks-not-for-everyone-and-everytime/#comment-1303 I realize that some of the pointed out problems are reasonable. Some of the issues may be solved by using right mock framework. You could give a try to this one: http://bitbucket.org/loomis/mockito-flex/. It is not record/replay. Instead it lets you verify only what you are interested in and stub only what you need to. Someone pointed out that this approach don't let you see problems in the code (as you may give up on specifying some of the interactions). I believe you can easily address it by adding enough tests that focus on the behavior of the function. I realize that some of the pointed out problems are reasonable. Some of the issues may be solved by using right mock framework. You could give a try to this one: http://bitbucket.org/loomis/mockito-flex/. It is not record/replay. Instead it lets you verify only what you are interested in and stub only what you need to. Someone pointed out that this approach don’t let you see problems in the code (as you may give up on specifying some of the interactions). I believe you can easily address it by adding enough tests that focus on the behavior of the function.

]]>