asunit-users

[Asunit-users] Mock-objects

[Marcelo de M. S. <cel...@gm...>]

Hi folks!

Where could I find some more information and samples on using the asunit
mock objects API ? I know the concept of mock-objects, however I'm not sure
how to use it together with asunit. I want to follow the "test-driven"
methodology and also develop the client side app first and feed it with mock
objects as need and then later "plug" the back-end. I know As2Lib has a
mock-object API, so, I'd also like to know which to use!

Thanks in advance,

Marcelo.

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

Re: [Asunit-users] Mock-objects

[Marcelo de M. S. <cel...@gm...>]

Hi Luke, thanks for the comprehensive explanation,

>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.

Hmmm, I thought this would be the greatest benefit as it would allow me to
really focus on one thing at a time and then adjust the little
inconsistencies later - isn't that what test-driven all about? (Design
first, implement later, in this case implement the server-side later)

Marcelo.

On 12/18/06, Luke Bayes <lb...@gm...> wrote:
>
> 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
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>
>

Re: [Asunit-users] Mock-objects

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

> Hmmm, I thought this would be the greatest benefit as it would allow me to
> really focus on one thing at a time and then adjust the little
> inconsistencies later - isn't that what test-driven all about? (Design
> first, implement later, in this case implement the server-side later)
>
> Marcelo.


Actually - TDD is about combining the design and implementation process into
a series of small steps. It helps us avoid making big design decisions about
how we think an application will work and instead lets us focus in on
implementing the "next most important thing".

With all that said, of course TDD does help you more cleanly separate the
different layers of an application, and writing tests around a service stub
(or mock) is highly recommended. The only issue I was trying to caution
against is if there were some other developers building the server
concurrently, make sure you're integrating early and often - as these two
layers often get implemented much differently than they're initially
designed. If you're building the sever *after* the client, this would be
much less of a problem.


Thanks,


Luke

Re: [Asunit-users] Mock-objects

[Marcelo de M. S. <cel...@gm...>]

Ah, that's much more clear now, thanks a lot for helping Luke!

On 12/19/06, Luke Bayes <lb...@gm...> wrote:
>
>
> Hmmm, I thought this would be the greatest benefit as it would allow me to
> > really focus on one thing at a time and then adjust the little
> > inconsistencies later - isn't that what test-driven all about? (Design
> > first, implement later, in this case implement the server-side later)
> >
> > Marcelo.
>
>
> Actually - TDD is about combining the design and implementation process
> into a series of small steps. It helps us avoid making big design decisions
> about how we think an application will work and instead lets us focus in on
> implementing the "next most important thing".
>
> With all that said, of course TDD does help you more cleanly separate the
> different layers of an application, and writing tests around a service stub
> (or mock) is highly recommended. The only issue I was trying to caution
> against is if there were some other developers building the server
> concurrently, make sure you're integrating early and often - as these two
> layers often get implemented much differently than they're initially
> designed. If you're building the sever *after* the client, this would be
> much less of a problem.
>
>
> Thanks,
>
>
> Luke
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Asunit-users mailing list
> Asu...@li...
> https://lists.sourceforge.net/lists/listinfo/asunit-users
>
>
>