Re: [Asunit-users] Mock-objects

[Luke B. <lb...@gm...>]

Hey Marcelo,

If you're using the XUL UI, you can ask it to create a Mock directly in the
interface and that should get it to generate the class under test, the mock
that extends it and a test case that uses the mock instead of the class.

We generally use mocks for our service layer and have them return faux /
expected results.

The idea is basically, that you have a Service class and a ServiceMock class
that extends it. You can override each of the methods that call out to the
network and create a faux result set - hopefully one that makes sense.

As far as building the client completely independently of the server, I
would encourage you to integrate early and often. It's far too easy to have
these two pieces fall out of sync, or have unexpected needs arise during
actual usage. A set of APIs that make sense in theory often don't make
nearly as much sense in practice.

The primary benefit of mocking the service layer is that when someone on one
team or another breaks on half of the application (client or server), the
other team isn't held up waiting for a patch.

As far as specific examples go, I'm not sure if there are any out there
right now - basically, you just extend the class under test, call the new
subclass ClassNameMock and use it in your TestCases... There are a couple of
good reasons to do this and many people name this object differently based
on it's purpose (mock vs.
stub<http://www.martinfowler.com/articles/mocksArentStubs.html>),
but I generally just name them 'mock' and get on with the task at hand.

Please let me know if you need more clarification, and I'll see what we can
do.


Thanks,


Luke Bayes
www.asunit.org