Comments on: MockMe: A new JavaScript mocking framework

By: zdennis

zdennis — Thu, 16 Oct 2008 23:54:16 +0000

Spies and mock expectations do couple you to how input / output collaborators are intended to be in use by a particular object. However, only doing “after the fact” state based verification requires that you have a test environment setup with all of the necessary object dependencies in place, and their dependencies in place. This is also coupling your test to implementation. Testing an object in isolation makes the object implementation clean as well as the the test.

Often times when you only do pure black-box testing the tests themselves can be difficult to understand and change because there is so much going on just to set up the testing environment.

Mocks are also a great design tool to discover interfaces you want to work with before it may exist. I think it’s more than a matter of taste. I think it’s understanding the value provided by which technique in a given situation, and choosing the appropriate one.

By: jlink

jlink — Thu, 14 Aug 2008 19:46:25 +0000

@ChrisInCambo:
IMO both spying and setting up mock expectations couples you to the implementation to some degree since collaboration (asking other objects to fullfill tasks for me can be considered an implementation detail). The trick is to do that only as much as needed.
That said, spying looks like less coupling to me (compared to mock expectations) because by default you only specify what you absolutely want to happen, whereas most mocking frameworks expect you to specify all calls by default.
Probably it’s a matter of taste. I changed from one style (expectations) to the other (after the fact verifications) after 7 years. It just feels more natural…

By: ChrisInCambo

ChrisInCambo — Wed, 13 Aug 2008 03:14:56 +0000

The spying technique is something I’ve read about but never used, but now we have framework so I can’t wait to give it a try next time I start a project.

@jlink: At first glance would I be wrong in saying that spying puts more emphasis on verification of what occurred during the life cycle of the spy rather than simply implementing an interface?
For me overuse of post use mock verification is in itself a testing smell as it is a way of verifying the indirect outputs of the system under test and therefore requires a knowledge of the internal workings of the class which depends on the mock/stub and moves us further away from ‘black box’ testing.

By: jlink

jlink — Tue, 12 Aug 2008 19:56:37 +0000

The biggest difference between Amok & Smoke on one side and MockMe on the other is that MockMe is a *spy* and not a *mock* framework. This leads to a different style of testing since – most of the time – you can be less specific in your tests with regards to your expected behaviour; this means that your tests will fail less often during refactoring.
Apart from that all three seem similar fit for doing their job.

By: ChrisInCambo

ChrisInCambo — Tue, 12 Aug 2008 08:39:41 +0000

You're not the only one holts, I think this is an area where the JavaScript community often falls well short of the mark. I've been trying to get some dialog on the subject going over at the AltDotJS Google Group. We're trying to put together a place where developers can discuss TDD/BDD, design patterns, agile, DSL's all within the context of JavaScript. So anyone who is interested in these subjects and others which don't get much air time at present please join the group and contribute. It seems like there's a run of testing tools being released for JavaScript at the moment. If you follow the link above there are details about two new JavaScript mocking frameworks (Amok and Smoke) and one new BDD testing framework (Screw Unit).

By: jmneter

jmneter — Tue, 12 Aug 2008 07:04:05 +0000

This looks better,just like IVR I use frequently.

By: holts

holts — Mon, 11 Aug 2008 18:31:39 +0000

I dig this. Looks cool.

I really wish there were more books on testing with JavaScript, Ruby, and Python. There are many great tools, take Ruby for example… Flexmock, Mocha, Rspec, etc… would love to see a book that really delved deep into best strategies and techniques for using them. Same goes for JS, which seems to be behind the curve with TDD practices.