mockobjects-java-dev

[Mockobjects-java-dev] Interested in participating

[<vt...@sy...>]

Hi all,

First of all thanks for the framework, it is of unvaluable use. Great =
work.=20

We have been developping servlets and were doing in-container testing up =
to recently. The limitations that we encountered forced us to look for a =
different testing approach until we read about mock objects. We used the =
mock objects servlet package, extended it for our own use, measured the =
benefits then decided to develop a mock objects JMS package (it works =
fine and serves us well). Now we plan to convert all our DAO unit tests =
to using mock objects.

Like with JUnit tests, since we tried mock objects, we have a hard time =
doing our tests any different way. So if you guys would accept some help =
we would be pleased to participate in the effort, being addicted mock =
objects users ourselves!

Regards,
Vincent Tenc=E9

Re: [Mockobjects-java-dev] Interested in participating

[Vincent M. <vm...@oc...>]

Hi Vince,

  ----- Original Message -----=20
  From: Vincent Tenc=E9=20
  To: moc...@li...=20
  Sent: Thursday, October 18, 2001 3:36 AM
  Subject: [Mockobjects-java-dev] Interested in participating


  Hi all,

  First of all thanks for the framework, it is of unvaluable use. Great =
work.=20

thanks :)

  We have been developping servlets and were doing in-container testing =
up to recently. The limitations that we encountered forced us to look =
for a different testing=20

I would be interested in hearing these as I'm participating to both =
Cactus (in-container testing) and Mock Objects. I have my own ideas on =
the pros and cons of each but would be very interested to hear from =
someone who has really used both approaches, on a real project.

  approach until we read about mock objects. We used the mock objects =
servlet package, extended it for our own use, measured the benefits then =
decided to develop a mock objects JMS package (it works fine and serves =
us well). Now we plan to convert all our DAO unit tests to using mock =
objects.

  Like with JUnit tests, since we tried mock objects, we have a hard =
time doing our tests any different way. So if you guys would accept some =
help we would be pleased to participate in the effort, being addicted =
mock objects users ourselves!

that's really great to hear ! :o) Welcome aboard.  I fear we haven't had =
as much time as we would like so far and any help is welcome. Have a =
look at CVS and choose what you'd like to do. Unfortunately we've not =
made a todo list yet. Maybe you could propose items for the todo list =
and volunteer for some of them ? These are the different areas where you =
could help :
- improve existing code and especially code that is not finished. The =
servlet mocks for example are far from being finished.
- improve build process
- improve web site documentation
- help answer to mailing-lists posts
- promote mock objects around you (I'm sure you're already doing that !)
- anything else you might think of

  Regards,
  Vincent Tenc=E9


-Vincent

--
Vincent Massol, vm...@oc...
OCTO Technology, www.octo.com
Information System Architecture Consulting

Re: [Mockobjects-java-dev] Interested in participating

[Vincent M. <vm...@oc...>]

Hi Vince,

I'm copying the list as I think they will find this question of =
interest.

  ----- Original Message -----=20
  From: Vincent Tenc=E9=20
  To: Vincent Massol=20
  Sent: Thursday, November 01, 2001 12:22 AM
  Subject: Re: [Mockobjects-java-dev] Interested in participating


  No pb. I myself have a lot of things to do at the moment. The project =
is entering in its final phase and the next month will be pretty crazy. =
I am afraid I wont have a lot of free time. We want to develop lots of =
mock objects for our domain classes and service classes and rewrite our =
tests using them.=20

use cactus, you don't need to write mocks ... No, I'm just teasing ... ! =
:)

  A quick question. We are always facing the same issue and I would like =
to know what is the approach you would recommend. The question is, how =
do we substitute our domain objects for mock implementations at runtime =
?

  Here is what we do currently:
  1) We define our domain/service objects in terms of abstract classes =
or preferably interfaces
  2) We add a Facade (for domain packages or service packages for =
instance) or a Factory (i.e. for DAOs) to create or access instances of =
objects
  3) We have a kind of JNDI registry that we lookup at runtime for =
components by role (like a specific service provider), roles are defined =
in terms of interfaces

  We can then setup our tests by binding to the registry mock =
implementations of specific components (roles) and our code under test =
looks the registry up and gets mock objects. I suppose you have faced =
this pb before. What was your approach ?

What I don't like too much witht this approach is that for testing =
consideration, you're going to suffer performance penalties and =
implement something more complex than it should be (I may not be =
understanding correctly what you said) :
- each call from one class to another will have to go through JNDI, =
instead of the standard intra JVM method to method call. Yes, you can =
improve the performance a bit by providing a facade/factory that would =
cache the objects but then you'll need to provide your own garbage =
collection mechanism ... What you are doing in effect is replacing the =
inter-class communication mechanism by providing a loosely coupled one. =
This can be a good architecture *but* at the component level and =
certainly not at the class level where you'll suffer horrible =
performances ...

What are the other options ? Answer : good design. A good design will =
try to minimise dependencies between classes. One solution is the IOC =
(inversion of control) pattern. In summary it says that instead of =
having your class instanciate some domain objects, they are passed to =
it.

For example, let's imagine that your class to test need to connect to a =
database. A first implementation could be :

Implementation 1:

public class MyClass
{
  public void doSomething()
  {
    // some JDBC code
  }
}

second implementation: you factor the code using the JDBC API in a =
JDBCWrapper class (or better yet, in a JDBCDataAccessService class, =
implementing a DataAccessService interface). Now, your doSomething() =
method does not use JDBC but rather the DataAccessService class :

Implementation 2:

public class MyClass
{
  public void doSomething()
  {
    DataAccess dataService =3D new JDBCDataAccess();
    // code that uses dataService
  }
}

This is better but not enough to be able to unit test MyClass. What we =
need is the possibility to replace JDBCDataAccess by a mock =
implementation. Instead of creating the object in doSomething(), you're =
going to let the caller pass the implementation to MyClass ... The =
result: your MyClass is now more generic and able to work with JDBC, =
with an OODB, with flat files, ... and with mocks ...

Implementation 3:

public class MyClass
{
  private DataAccessService service;

  public void setDataAccessService(DataAccessService service)
  {
    this.service =3D service;
  }

  public void doSomething()
  {
    // codde that uses this.service
  }

}

Note: if you want to be sure that setDataAccessService has been called, =
put it as a parameter of your constructor (or of the doSomething() =
method).

Now, your unit test :

public void testDoSomething()
{
  // init
  MockDataAccessService service =3D new MockDataAccessService();
  MyClass class =3D new MyClass();
  class.setDataAccessService(service);
=20
  // test
  class.doSomething();

  // verify
  assertEquals( .....);
}

-Vincent

PS: I hope I have understood your question !

  Thanks,
  Vincent

  ----- Original Message -----=20
    From: Vincent Massol=20
    To: Vincent Tenc=E9=20
    Sent: Wednesday, October 31, 2001 6:49 PM
    Subject: Re: [Mockobjects-java-dev] Interested in participating


    Vince, I just realized I have not answered to you. Sorry about that =
! can you wait 2 more days ... will do that this coming week end (It =
needs to thinking ... :) ).

    thanks
    cheers,
    -Vincent

    --
    Vincent Massol, vm...@oc...
    OCTO Technology, www.octo.com
    Information System Architecture Consulting
      ----- Original Message -----=20
      From: Vincent Tenc=E9=20
      To: Vincent Massol=20
      Cc: vin...@ge...=20
      Sent: Monday, October 22, 2001 2:20 AM
      Subject: Re: [Mockobjects-java-dev] Interested in participating


      Hi Vince,

      It's interesting to discuss the pros and cons of MockObjects vs =
in-container testing. We are using Catcus a part of our test strategy =
and we had some debates ourselves at the beginning on what was the best =
approach to use. We quickly realised though that both approaches were =
complementary.

      When the project began, the domain code was still rather simple =
and running tests was not an issue. But as soon as we added mor elogic =
(domain, crypto) and we started interfacing with external systems (DBs, =
JMS providers),  we notices that running tests took longer and longer. =
We had to develop simulators for external systems, create tests data for =
databases and back-end systems accessed through JMS as well as encrypted =
incoming data that would go through our cypto libs. It was rather =
frustating to see that frequently our domain code was bug-free but our =
simulators or data were corrupted. We measured that 2 times out of 3 =
tests failures were not due to our domain code. Worst, we had to fix the =
bugs before going on and we found it 2 to 3 times longer fixing those =
bugs simply because we had no tests to back up our simulators or test =
data!

      I didnt express myself correctly saying that we encountered =
limitations with our in-container testing strategy. It was rather our =
test strategy as a whole that proved to be poor. Mock objects solved a =
lot of our problems with its capacity to do really fine grained unit =
tests. We rewrote some of the critical tests that caused problems (DBs, =
JMS, Crypto) and now those tests run correclty 100% of the time. We =
still use Cactus, but at a much higher level, to test our use cases. So =
its like integration tests on a use case by use case basis.

      To focus on the discussion Mock vs In-container, in our opinion =
one of the big advantage of mock objects is the capacity to write very =
focused unit tests and sometimes testing pieces of code it would be =
difficult to test otherwise. The tests can run very quickly and =
independently (most of the time) of external settings ensuring that once =
they have passed, we dont have to worry about them anymore. A side =
effect of using mock objects was that we ended up writing better code, =
thought more in terns of interfaces, removing unecessary dependencies =
between domain objects and singletons for instance.
      On the other hand, using mo proved to be challenging and it still =
is. It took time to understand and use them properly, then it took time =
to write our own properly (respecting the concepts). We also had to =
change parts of our code to introduce the mock objects, adding factories =
and registry so that domain objects implementations can be replaced by =
mock objects implementations during testing. But once they are written, =
like tests, we can leverage mo on subsequent projects.

      I would imagine that If you participate in both Catcus and MO, you =
also feel that both approaches are complementary :-)

      I will be very busy in the next weeks or so on my project, but I =
can still spare some free time to help on the project. Let me think of =
the best way for me to help.

      Regards,
      Vincent

      ----- Original Message -----=20
        From: Vincent Massol=20
        To: Vincent Tenc=E9 ; moc...@li... =

        Sent: Thursday, October 18, 2001 4:36 AM
        Subject: Re: [Mockobjects-java-dev] Interested in participating


        Hi Vince,

          ----- Original Message -----=20
          From: Vincent Tenc=E9=20
          To: moc...@li...=20
          Sent: Thursday, October 18, 2001 3:36 AM
          Subject: [Mockobjects-java-dev] Interested in participating


          Hi all,

          First of all thanks for the framework, it is of unvaluable =
use. Great work.=20

        thanks :)

          We have been developping servlets and were doing in-container =
testing up to recently. The limitations that we encountered forced us to =
look for a different testing=20

        I would be interested in hearing these as I'm participating to =
both Cactus (in-container testing) and Mock Objects. I have my own ideas =
on the pros and cons of each but would be very interested to hear from =
someone who has really used both approaches, on a real project.

          approach until we read about mock objects. We used the mock =
objects servlet package, extended it for our own use, measured the =
benefits then decided to develop a mock objects JMS package (it works =
fine and serves us well). Now we plan to convert all our DAO unit tests =
to using mock objects.

          Like with JUnit tests, since we tried mock objects, we have a =
hard time doing our tests any different way. So if you guys would accept =
some help we would be pleased to participate in the effort, being =
addicted mock objects users ourselves!

        that's really great to hear ! :o) Welcome aboard.  I fear we =
haven't had as much time as we would like so far and any help is =
welcome. Have a look at CVS and choose what you'd like to do. =
Unfortunately we've not made a todo list yet. Maybe you could propose =
items for the todo list and volunteer for some of them ? These are the =
different areas where you could help :
        - improve existing code and especially code that is not =
finished. The servlet mocks for example are far from being finished.
        - improve build process
        - improve web site documentation
        - help answer to mailing-lists posts
        - promote mock objects around you (I'm sure you're already doing =
that !)
        - anything else you might think of

          Regards,
          Vincent Tenc=E9


        -Vincent

        --
        Vincent Massol, vm...@oc...
        OCTO Technology, www.octo.com
        Information System Architecture Consulting

RE: [Mockobjects-java-dev] Interested in participating

[Tim M. <tim...@po...>]

Nice answer Vincent - the only modification I would make would be that
instead of having:

  class.setDataAccessService(service);

I would put the ability to set a service in the constructor (unless you
really have a need to dynamically switch services at runtime - as I think
this is clearer). You can then provide a default constructor that does
something like:

this(new Service())

Tim

 -----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Vincent Massol
Sent: 2 November 2001 8:46 pm
To: Vincent Tencé
Cc: moc...@li...
Subject: Re: [Mockobjects-java-dev] Interested in participating


  Hi Vince,

  I'm copying the list as I think they will find this question of interest.

    ----- Original Message -----
    From: Vincent Tencé
    To: Vincent Massol
    Sent: Thursday, November 01, 2001 12:22 AM
    Subject: Re: [Mockobjects-java-dev] Interested in participating


    No pb. I myself have a lot of things to do at the moment. The project is
entering in its final phase and the next month will be pretty crazy. I am
afraid I wont have a lot of free time. We want to develop lots of mock
objects for our domain classes and service classes and rewrite our tests
using them.

  use cactus, you don't need to write mocks ... No, I'm just teasing ... !
:)

    A quick question. We are always facing the same issue and I would like
to know what is the approach you would recommend. The question is, how do we
substitute our domain objects for mock implementations at runtime ?

    Here is what we do currently:
    1) We define our domain/service objects in terms of abstract classes or
preferably interfaces
    2) We add a Facade (for domain packages or service packages for
instance) or a Factory (i.e. for DAOs) to create or access instances of
objects
    3) We have a kind of JNDI registry that we lookup at runtime for
components by role (like a specific service provider), roles are defined in
terms of interfaces

    We can then setup our tests by binding to the registry mock
implementations of specific components (roles) and our code under test looks
the registry up and gets mock objects. I suppose you have faced this pb
before. What was your approach ?

  What I don't like too much witht this approach is that for testing
consideration, you're going to suffer performance penalties and implement
something more complex than it should be (I may not be understanding
correctly what you said) :
  - each call from one class to another will have to go through JNDI,
instead of the standard intra JVM method to method call. Yes, you can
improve the performance a bit by providing a facade/factory that would cache
the objects but then you'll need to provide your own garbage collection
mechanism ... What you are doing in effect is replacing the inter-class
communication mechanism by providing a loosely coupled one. This can be a
good architecture *but* at the component level and certainly not at the
class level where you'll suffer horrible performances ...

  What are the other options ? Answer : good design. A good design will try
to minimise dependencies between classes. One solution is the IOC (inversion
of control) pattern. In summary it says that instead of having your class
instanciate some domain objects, they are passed to it.

  For example, let's imagine that your class to test need to connect to a
database. A first implementation could be :

  Implementation 1:

  public class MyClass
  {
    public void doSomething()
    {
      // some JDBC code
    }
  }

  second implementation: you factor the code using the JDBC API in a
JDBCWrapper class (or better yet, in a JDBCDataAccessService class,
implementing a DataAccessService interface). Now, your doSomething() method
does not use JDBC but rather the DataAccessService class :

  Implementation 2:

  public class MyClass
  {
    public void doSomething()
    {
      DataAccess dataService = new JDBCDataAccess();
      // code that uses dataService
    }
  }

  This is better but not enough to be able to unit test MyClass. What we
need is the possibility to replace JDBCDataAccess by a mock implementation.
Instead of creating the object in doSomething(), you're going to let the
caller pass the implementation to MyClass ... The result: your MyClass is
now more generic and able to work with JDBC, with an OODB, with flat files,
... and with mocks ...

  Implementation 3:

  public class MyClass
  {
    private DataAccessService service;

    public void setDataAccessService(DataAccessService service)
    {
      this.service = service;
    }

    public void doSomething()
    {
      // codde that uses this.service
    }

  }

  Note: if you want to be sure that setDataAccessService has been called,
put it as a parameter of your constructor (or of the doSomething() method).

  Now, your unit test :

  public void testDoSomething()
  {
    // init
    MockDataAccessService service = new MockDataAccessService();
    MyClass class = new MyClass();
    class.setDataAccessService(service);

    // test
    class.doSomething();

    // verify
    assertEquals( .....);
  }

  -Vincent

  PS: I hope I have understood your question !

    Thanks,
    Vincent

    ----- Original Message -----
      From: Vincent Massol
      To: Vincent Tencé
      Sent: Wednesday, October 31, 2001 6:49 PM
      Subject: Re: [Mockobjects-java-dev] Interested in participating


      Vince, I just realized I have not answered to you. Sorry about that !
can you wait 2 more days ... will do that this coming week end (It needs to
thinking ... :) ).

      thanks
      cheers,
      -Vincent

      --
      Vincent Massol, vm...@oc...
      OCTO Technology, www.octo.com
      Information System Architecture Consulting
        ----- Original Message -----
        From: Vincent Tencé
        To: Vincent Massol
        Cc: vin...@ge...
        Sent: Monday, October 22, 2001 2:20 AM
        Subject: Re: [Mockobjects-java-dev] Interested in participating


        Hi Vince,

        It's interesting to discuss the pros and cons of MockObjects vs
in-container testing. We are using Catcus a part of our test strategy and we
had some debates ourselves at the beginning on what was the best approach to
use. We quickly realised though that both approaches were complementary.

        When the project began, the domain code was still rather simple and
running tests was not an issue. But as soon as we added mor elogic (domain,
crypto) and we started interfacing with external systems (DBs, JMS
providers),  we notices that running tests took longer and longer. We had to
develop simulators for external systems, create tests data for databases and
back-end systems accessed through JMS as well as encrypted incoming data
that would go through our cypto libs. It was rather frustating to see that
frequently our domain code was bug-free but our simulators or data were
corrupted. We measured that 2 times out of 3 tests failures were not due to
our domain code. Worst, we had to fix the bugs before going on and we found
it 2 to 3 times longer fixing those bugs simply because we had no tests to
back up our simulators or test data!

        I didnt express myself correctly saying that we encountered
limitations with our in-container testing strategy. It was rather our test
strategy as a whole that proved to be poor. Mock objects solved a lot of our
problems with its capacity to do really fine grained unit tests. We rewrote
some of the critical tests that caused problems (DBs, JMS, Crypto) and now
those tests run correclty 100% of the time. We still use Cactus, but at a
much higher level, to test our use cases. So its like integration tests on a
use case by use case basis.

        To focus on the discussion Mock vs In-container, in our opinion one
of the big advantage of mock objects is the capacity to write very focused
unit tests and sometimes testing pieces of code it would be difficult to
test otherwise. The tests can run very quickly and independently (most of
the time) of external settings ensuring that once they have passed, we dont
have to worry about them anymore. A side effect of using mock objects was
that we ended up writing better code, thought more in terns of interfaces,
removing unecessary dependencies between domain objects and singletons for
instance.
        On the other hand, using mo proved to be challenging and it still
is. It took time to understand and use them properly, then it took time to
write our own properly (respecting the concepts). We also had to change
parts of our code to introduce the mock objects, adding factories and
registry so that domain objects implementations can be replaced by mock
objects implementations during testing. But once they are written, like
tests, we can leverage mo on subsequent projects.

        I would imagine that If you participate in both Catcus and MO, you
also feel that both approaches are complementary :-)

        I will be very busy in the next weeks or so on my project, but I can
still spare some free time to help on the project. Let me think of the best
way for me to help.

        Regards,
        Vincent

        ----- Original Message -----
          From: Vincent Massol
          To: Vincent Tencé ; moc...@li...
          Sent: Thursday, October 18, 2001 4:36 AM
          Subject: Re: [Mockobjects-java-dev] Interested in participating


          Hi Vince,

            ----- Original Message -----
            From: Vincent Tencé
            To: moc...@li...
            Sent: Thursday, October 18, 2001 3:36 AM
            Subject: [Mockobjects-java-dev] Interested in participating


            Hi all,

            First of all thanks for the framework, it is of unvaluable use.
Great work.

          thanks :)

            We have been developping servlets and were doing in-container
testing up to recently. The limitations that we encountered forced us to
look for a different testing

          I would be interested in hearing these as I'm participating to
both Cactus (in-container testing) and Mock Objects. I have my own ideas on
the pros and cons of each but would be very interested to hear from someone
who has really used both approaches, on a real project.

            approach until we read about mock objects. We used the mock
objects servlet package, extended it for our own use, measured the benefits
then decided to develop a mock objects JMS package (it works fine and serves
us well). Now we plan to convert all our DAO unit tests to using mock
objects.

            Like with JUnit tests, since we tried mock objects, we have a
hard time doing our tests any different way. So if you guys would accept
some help we would be pleased to participate in the effort, being addicted
mock objects users ourselves!

          that's really great to hear ! :o) Welcome aboard.  I fear we
haven't had as much time as we would like so far and any help is welcome.
Have a look at CVS and choose what you'd like to do. Unfortunately we've not
made a todo list yet. Maybe you could propose items for the todo list and
volunteer for some of them ? These are the different areas where you could
help :
          - improve existing code and especially code that is not finished.
The servlet mocks for example are far from being finished.
          - improve build process
          - improve web site documentation
          - help answer to mailing-lists posts
          - promote mock objects around you (I'm sure you're already doing
that !)
          - anything else you might think of

            Regards,
            Vincent Tencé


          -Vincent

          --
          Vincent Massol, vm...@oc...
          OCTO Technology, www.octo.com
          Information System Architecture Consulting

Re: [Mockobjects-java-dev] Interested in participating

[Vincent M. <vm...@oc...>]

  ----- Original Message -----=20
  From: Tim Mackinnon=20
  To: Vincent Massol ; Vincent Tenc=E9=20
  Cc: moc...@li...=20
  Sent: Sunday, November 04, 2001 11:11 PM
  Subject: RE: [Mockobjects-java-dev] Interested in participating


  Nice answer Vincent - the only modification I would make would be that =
instead of having:

    class.setDataAccessService(service);

  I would put the ability to set a service in the constructor (unless =
you really have a need to dynamically switch services at runtime - as I =
think this is clearer). You can then provide a default constructor that =
does something like:

  this(new Service())

thanks Tim ... :) I agree completely with you and actually even =
suggested that in my response : "Note: if you want to be sure that =
setDataAccessService has been called, put it as a parameter of your =
constructor (or of the doSomething() method)". Of course, you're =
explaining it better here ... :-)

cheers,
-Vincent


  Tim

   -----Original Message-----
  From: moc...@li... =
[mailto:moc...@li...]On Behalf Of =
Vincent Massol
  Sent: 2 November 2001 8:46 pm
  To: Vincent Tenc=E9
  Cc: moc...@li...
  Subject: Re: [Mockobjects-java-dev] Interested in participating


    Hi Vince,

    I'm copying the list as I think they will find this question of =
interest.

      ----- Original Message -----=20
      From: Vincent Tenc=E9=20
      To: Vincent Massol=20
      Sent: Thursday, November 01, 2001 12:22 AM
      Subject: Re: [Mockobjects-java-dev] Interested in participating


      No pb. I myself have a lot of things to do at the moment. The =
project is entering in its final phase and the next month will be pretty =
crazy. I am afraid I wont have a lot of free time. We want to develop =
lots of mock objects for our domain classes and service classes and =
rewrite our tests using them.=20

    use cactus, you don't need to write mocks ... No, I'm just teasing =
... ! :)

      A quick question. We are always facing the same issue and I would =
like to know what is the approach you would recommend. The question is, =
how do we substitute our domain objects for mock implementations at =
runtime ?

      Here is what we do currently:
      1) We define our domain/service objects in terms of abstract =
classes or preferably interfaces
      2) We add a Facade (for domain packages or service packages for =
instance) or a Factory (i.e. for DAOs) to create or access instances of =
objects
      3) We have a kind of JNDI registry that we lookup at runtime for =
components by role (like a specific service provider), roles are defined =
in terms of interfaces

      We can then setup our tests by binding to the registry mock =
implementations of specific components (roles) and our code under test =
looks the registry up and gets mock objects. I suppose you have faced =
this pb before. What was your approach ?

    What I don't like too much witht this approach is that for testing =
consideration, you're going to suffer performance penalties and =
implement something more complex than it should be (I may not be =
understanding correctly what you said) :
    - each call from one class to another will have to go through JNDI, =
instead of the standard intra JVM method to method call. Yes, you can =
improve the performance a bit by providing a facade/factory that would =
cache the objects but then you'll need to provide your own garbage =
collection mechanism ... What you are doing in effect is replacing the =
inter-class communication mechanism by providing a loosely coupled one. =
This can be a good architecture *but* at the component level and =
certainly not at the class level where you'll suffer horrible =
performances ...

    What are the other options ? Answer : good design. A good design =
will try to minimise dependencies between classes. One solution is the =
IOC (inversion of control) pattern. In summary it says that instead of =
having your class instanciate some domain objects, they are passed to =
it.

    For example, let's imagine that your class to test need to connect =
to a database. A first implementation could be :

    Implementation 1:

    public class MyClass
    {
      public void doSomething()
      {
        // some JDBC code
      }
    }

    second implementation: you factor the code using the JDBC API in a =
JDBCWrapper class (or better yet, in a JDBCDataAccessService class, =
implementing a DataAccessService interface). Now, your doSomething() =
method does not use JDBC but rather the DataAccessService class :

    Implementation 2:

    public class MyClass
    {
      public void doSomething()
      {
        DataAccess dataService =3D new JDBCDataAccess();
        // code that uses dataService
      }
    }

    This is better but not enough to be able to unit test MyClass. What =
we need is the possibility to replace JDBCDataAccess by a mock =
implementation. Instead of creating the object in doSomething(), you're =
going to let the caller pass the implementation to MyClass ... The =
result: your MyClass is now more generic and able to work with JDBC, =
with an OODB, with flat files, ... and with mocks ...

    Implementation 3:

    public class MyClass
    {
      private DataAccessService service;

      public void setDataAccessService(DataAccessService service)
      {
        this.service =3D service;
      }

      public void doSomething()
      {
        // codde that uses this.service
      }

    }

    Note: if you want to be sure that setDataAccessService has been =
called, put it as a parameter of your constructor (or of the =
doSomething() method).

    Now, your unit test :

    public void testDoSomething()
    {
      // init
      MockDataAccessService service =3D new MockDataAccessService();
      MyClass class =3D new MyClass();
      class.setDataAccessService(service);

      // test
      class.doSomething();

      // verify
      assertEquals( .....);
    }

    -Vincent

    PS: I hope I have understood your question !

      Thanks,
      Vincent

      ----- Original Message -----=20
        From: Vincent Massol=20
        To: Vincent Tenc=E9=20
        Sent: Wednesday, October 31, 2001 6:49 PM
        Subject: Re: [Mockobjects-java-dev] Interested in participating


        Vince, I just realized I have not answered to you. Sorry about =
that ! can you wait 2 more days ... will do that this coming week end =
(It needs to thinking ... :) ).

        thanks
        cheers,
        -Vincent

        --
        Vincent Massol, vm...@oc...
        OCTO Technology, www.octo.com
        Information System Architecture Consulting
          ----- Original Message -----=20
          From: Vincent Tenc=E9=20
          To: Vincent Massol=20
          Cc: vin...@ge...=20
          Sent: Monday, October 22, 2001 2:20 AM
          Subject: Re: [Mockobjects-java-dev] Interested in =
participating


          Hi Vince,

          It's interesting to discuss the pros and cons of MockObjects =
vs in-container testing. We are using Catcus a part of our test strategy =
and we had some debates ourselves at the beginning on what was the best =
approach to use. We quickly realised though that both approaches were =
complementary.

          When the project began, the domain code was still rather =
simple and running tests was not an issue. But as soon as we added mor =
elogic (domain, crypto) and we started interfacing with external systems =
(DBs, JMS providers),  we notices that running tests took longer and =
longer. We had to develop simulators for external systems, create tests =
data for databases and back-end systems accessed through JMS as well as =
encrypted incoming data that would go through our cypto libs. It was =
rather frustating to see that frequently our domain code was bug-free =
but our simulators or data were corrupted. We measured that 2 times out =
of 3 tests failures were not due to our domain code. Worst, we had to =
fix the bugs before going on and we found it 2 to 3 times longer fixing =
those bugs simply because we had no tests to back up our simulators or =
test data!

          I didnt express myself correctly saying that we encountered =
limitations with our in-container testing strategy. It was rather our =
test strategy as a whole that proved to be poor. Mock objects solved a =
lot of our problems with its capacity to do really fine grained unit =
tests. We rewrote some of the critical tests that caused problems (DBs, =
JMS, Crypto) and now those tests run correclty 100% of the time. We =
still use Cactus, but at a much higher level, to test our use cases. So =
its like integration tests on a use case by use case basis.

          To focus on the discussion Mock vs In-container, in our =
opinion one of the big advantage of mock objects is the capacity to =
write very focused unit tests and sometimes testing pieces of code it =
would be difficult to test otherwise. The tests can run very quickly and =
independently (most of the time) of external settings ensuring that once =
they have passed, we dont have to worry about them anymore. A side =
effect of using mock objects was that we ended up writing better code, =
thought more in terns of interfaces, removing unecessary dependencies =
between domain objects and singletons for instance.
          On the other hand, using mo proved to be challenging and it =
still is. It took time to understand and use them properly, then it took =
time to write our own properly (respecting the concepts). We also had to =
change parts of our code to introduce the mock objects, adding factories =
and registry so that domain objects implementations can be replaced by =
mock objects implementations during testing. But once they are written, =
like tests, we can leverage mo on subsequent projects.

          I would imagine that If you participate in both Catcus and MO, =
you also feel that both approaches are complementary :-)

          I will be very busy in the next weeks or so on my project, but =
I can still spare some free time to help on the project. Let me think of =
the best way for me to help.

          Regards,
          Vincent

          ----- Original Message -----=20
            From: Vincent Massol=20
            To: Vincent Tenc=E9 ; =
moc...@li...=20
            Sent: Thursday, October 18, 2001 4:36 AM
            Subject: Re: [Mockobjects-java-dev] Interested in =
participating


            Hi Vince,

              ----- Original Message -----=20
              From: Vincent Tenc=E9=20
              To: moc...@li...=20
              Sent: Thursday, October 18, 2001 3:36 AM
              Subject: [Mockobjects-java-dev] Interested in =
participating


              Hi all,

              First of all thanks for the framework, it is of unvaluable =
use. Great work.=20

            thanks :)

              We have been developping servlets and were doing =
in-container testing up to recently. The limitations that we encountered =
forced us to look for a different testing=20

            I would be interested in hearing these as I'm participating =
to both Cactus (in-container testing) and Mock Objects. I have my own =
ideas on the pros and cons of each but would be very interested to hear =
from someone who has really used both approaches, on a real project.

              approach until we read about mock objects. We used the =
mock objects servlet package, extended it for our own use, measured the =
benefits then decided to develop a mock objects JMS package (it works =
fine and serves us well). Now we plan to convert all our DAO unit tests =
to using mock objects.

              Like with JUnit tests, since we tried mock objects, we =
have a hard time doing our tests any different way. So if you guys would =
accept some help we would be pleased to participate in the effort, being =
addicted mock objects users ourselves!

            that's really great to hear ! :o) Welcome aboard.  I fear we =
haven't had as much time as we would like so far and any help is =
welcome. Have a look at CVS and choose what you'd like to do. =
Unfortunately we've not made a todo list yet. Maybe you could propose =
items for the todo list and volunteer for some of them ? These are the =
different areas where you could help :
            - improve existing code and especially code that is not =
finished. The servlet mocks for example are far from being finished.
            - improve build process
            - improve web site documentation
            - help answer to mailing-lists posts
            - promote mock objects around you (I'm sure you're already =
doing that !)
            - anything else you might think of

              Regards,
              Vincent Tenc=E9


            -Vincent

            --
            Vincent Massol, vm...@oc...
            OCTO Technology, www.octo.com
            Information System Architecture Consulting

Re: [Mockobjects-java-dev] Interested in participating

[<vt...@sy...>]

Thanks for the answer.

You understood the question right, except for the fact that we dont use =
JNDI but a simple in memory registry implementation, so its a standard =
JMV call and we dont suffer the performance penalty.=20

I like what you propose. This is effectively the way for us to remove a =
lot of annoying code going to that in memory registry to access a =
service or factory. If I got you right, my DataAccessService classes can =
be passed a DataSource so I can use mock implementations of data sources =
for test. My Domain classes are passed a DAO factory so I can use mock =
DataAccessService classes as well. My use case controllers (classes that =
use domain objects) are passed a business facade which I can substitute =
at runtime too for one that will return mock domain classes if I wish. =
Up to the point where my startup component (which doesnt use any use =
case controller but just start them for instance, do I dont need to test =
it against mock objects) is responsible for instanciating the business =
facade. Damn I like it :-)

Thanks
Vincent



From: Vincent Massol=20
  To: Vincent Tenc=E9=20
  Cc: moc...@li...=20
  Sent: Friday, November 02, 2001 3:46 PM
  Subject: Re: [Mockobjects-java-dev] Interested in participating


  Hi Vince,

  I'm copying the list as I think they will find this question of =
interest.

    ----- Original Message -----=20
    From: Vincent Tenc=E9=20
    To: Vincent Massol=20
    Sent: Thursday, November 01, 2001 12:22 AM
    Subject: Re: [Mockobjects-java-dev] Interested in participating


    No pb. I myself have a lot of things to do at the moment. The =
project is entering in its final phase and the next month will be pretty =
crazy. I am afraid I wont have a lot of free time. We want to develop =
lots of mock objects for our domain classes and service classes and =
rewrite our tests using them.=20

  use cactus, you don't need to write mocks ... No, I'm just teasing ... =
! :)

    A quick question. We are always facing the same issue and I would =
like to know what is the approach you would recommend. The question is, =
how do we substitute our domain objects for mock implementations at =
runtime ?

    Here is what we do currently:
    1) We define our domain/service objects in terms of abstract classes =
or preferably interfaces
    2) We add a Facade (for domain packages or service packages for =
instance) or a Factory (i.e. for DAOs) to create or access instances of =
objects
    3) We have a kind of JNDI registry that we lookup at runtime for =
components by role (like a specific service provider), roles are defined =
in terms of interfaces

    We can then setup our tests by binding to the registry mock =
implementations of specific components (roles) and our code under test =
looks the registry up and gets mock objects. I suppose you have faced =
this pb before. What was your approach ?

  What I don't like too much witht this approach is that for testing =
consideration, you're going to suffer performance penalties and =
implement something more complex than it should be (I may not be =
understanding correctly what you said) :
  - each call from one class to another will have to go through JNDI, =
instead of the standard intra JVM method to method call. Yes, you can =
improve the performance a bit by providing a facade/factory that would =
cache the objects but then you'll need to provide your own garbage =
collection mechanism ... What you are doing in effect is replacing the =
inter-class communication mechanism by providing a loosely coupled one. =
This can be a good architecture *but* at the component level and =
certainly not at the class level where you'll suffer horrible =
performances ...

  What are the other options ? Answer : good design. A good design will =
try to minimise dependencies between classes. One solution is the IOC =
(inversion of control) pattern. In summary it says that instead of =
having your class instanciate some domain objects, they are passed to =
it.

  For example, let's imagine that your class to test need to connect to =
a database. A first implementation could be :

  Implementation 1:

  public class MyClass
  {
    public void doSomething()
    {
      // some JDBC code
    }
  }

  second implementation: you factor the code using the JDBC API in a =
JDBCWrapper class (or better yet, in a JDBCDataAccessService class, =
implementing a DataAccessService interface). Now, your doSomething() =
method does not use JDBC but rather the DataAccessService class :

  Implementation 2:

  public class MyClass
  {
    public void doSomething()
    {
      DataAccess dataService =3D new JDBCDataAccess();
      // code that uses dataService
    }
  }

  This is better but not enough to be able to unit test MyClass. What we =
need is the possibility to replace JDBCDataAccess by a mock =
implementation. Instead of creating the object in doSomething(), you're =
going to let the caller pass the implementation to MyClass ... The =
result: your MyClass is now more generic and able to work with JDBC, =
with an OODB, with flat files, ... and with mocks ...

  Implementation 3:

  public class MyClass
  {
    private DataAccessService service;

    public void setDataAccessService(DataAccessService service)
    {
      this.service =3D service;
    }

    public void doSomething()
    {
      // codde that uses this.service
    }

  }

  Note: if you want to be sure that setDataAccessService has been =
called, put it as a parameter of your constructor (or of the =
doSomething() method).

  Now, your unit test :

  public void testDoSomething()
  {
    // init
    MockDataAccessService service =3D new MockDataAccessService();
    MyClass class =3D new MyClass();
    class.setDataAccessService(service);

    // test
    class.doSomething();

    // verify
    assertEquals( .....);
  }

  -Vincent

  PS: I hope I have understood your question !

    Thanks,
    Vincent

    ----- Original Message -----=20
      From: Vincent Massol=20
      To: Vincent Tenc=E9=20
      Sent: Wednesday, October 31, 2001 6:49 PM
      Subject: Re: [Mockobjects-java-dev] Interested in participating


      Vince, I just realized I have not answered to you. Sorry about =
that ! can you wait 2 more days ... will do that this coming week end =
(It needs to thinking ... :) ).

      thanks
      cheers,
      -Vincent

      --
      Vincent Massol, vm...@oc...
      OCTO Technology, www.octo.com
      Information System Architecture Consulting
        ----- Original Message -----=20
        From: Vincent Tenc=E9=20
        To: Vincent Massol=20
        Cc: vin...@ge...=20
        Sent: Monday, October 22, 2001 2:20 AM
        Subject: Re: [Mockobjects-java-dev] Interested in participating


        Hi Vince,

        It's interesting to discuss the pros and cons of MockObjects vs =
in-container testing. We are using Catcus a part of our test strategy =
and we had some debates ourselves at the beginning on what was the best =
approach to use. We quickly realised though that both approaches were =
complementary.

        When the project began, the domain code was still rather simple =
and running tests was not an issue. But as soon as we added mor elogic =
(domain, crypto) and we started interfacing with external systems (DBs, =
JMS providers),  we notices that running tests took longer and longer. =
We had to develop simulators for external systems, create tests data for =
databases and back-end systems accessed through JMS as well as encrypted =
incoming data that would go through our cypto libs. It was rather =
frustating to see that frequently our domain code was bug-free but our =
simulators or data were corrupted. We measured that 2 times out of 3 =
tests failures were not due to our domain code. Worst, we had to fix the =
bugs before going on and we found it 2 to 3 times longer fixing those =
bugs simply because we had no tests to back up our simulators or test =
data!

        I didnt express myself correctly saying that we encountered =
limitations with our in-container testing strategy. It was rather our =
test strategy as a whole that proved to be poor. Mock objects solved a =
lot of our problems with its capacity to do really fine grained unit =
tests. We rewrote some of the critical tests that caused problems (DBs, =
JMS, Crypto) and now those tests run correclty 100% of the time. We =
still use Cactus, but at a much higher level, to test our use cases. So =
its like integration tests on a use case by use case basis.

        To focus on the discussion Mock vs In-container, in our opinion =
one of the big advantage of mock objects is the capacity to write very =
focused unit tests and sometimes testing pieces of code it would be =
difficult to test otherwise. The tests can run very quickly and =
independently (most of the time) of external settings ensuring that once =
they have passed, we dont have to worry about them anymore. A side =
effect of using mock objects was that we ended up writing better code, =
thought more in terns of interfaces, removing unecessary dependencies =
between domain objects and singletons for instance.
        On the other hand, using mo proved to be challenging and it =
still is. It took time to understand and use them properly, then it took =
time to write our own properly (respecting the concepts). We also had to =
change parts of our code to introduce the mock objects, adding factories =
and registry so that domain objects implementations can be replaced by =
mock objects implementations during testing. But once they are written, =
like tests, we can leverage mo on subsequent projects.

        I would imagine that If you participate in both Catcus and MO, =
you also feel that both approaches are complementary :-)

        I will be very busy in the next weeks or so on my project, but I =
can still spare some free time to help on the project. Let me think of =
the best way for me to help.

        Regards,
        Vincent

        ----- Original Message -----=20
          From: Vincent Massol=20
          To: Vincent Tenc=E9 ; =
moc...@li...=20
          Sent: Thursday, October 18, 2001 4:36 AM
          Subject: Re: [Mockobjects-java-dev] Interested in =
participating


          Hi Vince,

            ----- Original Message -----=20
            From: Vincent Tenc=E9=20
            To: moc...@li...=20
            Sent: Thursday, October 18, 2001 3:36 AM
            Subject: [Mockobjects-java-dev] Interested in participating


            Hi all,

            First of all thanks for the framework, it is of unvaluable =
use. Great work.=20

          thanks :)

            We have been developping servlets and were doing =
in-container testing up to recently. The limitations that we encountered =
forced us to look for a different testing=20

          I would be interested in hearing these as I'm participating to =
both Cactus (in-container testing) and Mock Objects. I have my own ideas =
on the pros and cons of each but would be very interested to hear from =
someone who has really used both approaches, on a real project.

            approach until we read about mock objects. We used the mock =
objects servlet package, extended it for our own use, measured the =
benefits then decided to develop a mock objects JMS package (it works =
fine and serves us well). Now we plan to convert all our DAO unit tests =
to using mock objects.

            Like with JUnit tests, since we tried mock objects, we have =
a hard time doing our tests any different way. So if you guys would =
accept some help we would be pleased to participate in the effort, being =
addicted mock objects users ourselves!

          that's really great to hear ! :o) Welcome aboard.  I fear we =
haven't had as much time as we would like so far and any help is =
welcome. Have a look at CVS and choose what you'd like to do. =
Unfortunately we've not made a todo list yet. Maybe you could propose =
items for the todo list and volunteer for some of them ? These are the =
different areas where you could help :
          - improve existing code and especially code that is not =
finished. The servlet mocks for example are far from being finished.
          - improve build process
          - improve web site documentation
          - help answer to mailing-lists posts
          - promote mock objects around you (I'm sure you're already =
doing that !)
          - anything else you might think of

            Regards,
            Vincent Tenc=E9


          -Vincent

          --
          Vincent Massol, vm...@oc...
          OCTO Technology, www.octo.com
          Information System Architecture Consulting

Re: [Mockobjects-java-dev] Interested in participating

[Vincent M. <vm...@oc...>]

  ----- Original Message -----=20
  From: Vincent Tenc=E9=20
  To: Vincent Massol=20
  Cc: vin...@ge...=20
  Sent: Monday, October 22, 2001 2:20 AM
  Subject: Re: [Mockobjects-java-dev] Interested in participating


  Hi Vince,

  It's interesting to discuss the pros and cons of MockObjects vs =
in-container testing. We are using Catcus a part of our test strategy =
and we had some debates ourselves at the beginning on what was the best =
approach to use. We quickly realised though that both approaches were =
complementary.

indeed, although there are still several possibilities :
- MO + Cactus + Acceptance tests : the best solution but this is =
probably for the most test-infected !
- MO + Acceptance tests : may be enough but my belief is that containers =
will play a more and more important role in the future and integration =
testing will become predominant in the global testing strategy [we can =
already see this with complex ebusiness applications]. Also, you are =
shielded from deployment and production issues which I don't believe is =
very good.
- Cactus + Acceptance tests : may be enough and focuses on preparing =
your application to production. Tests take longer to execute but you can =
still run them several times a day. It helps you get control of your =
integration environment and start thinking about hard issues. It also =
prepares you for stress testing/acceptance testing.


  When the project began, the domain code was still rather simple and =
running tests was not an issue. But as soon as we added mor elogic =
(domain, crypto) and we started interfacing with external systems (DBs, =
JMS providers),  we notices that running tests took longer and longer. =
We had to develop simulators for external systems, create tests data for =
databases and back-end systems accessed through JMS as well as encrypted =
incoming data that would go through our cypto libs. It was rather =
frustating to see that frequently our domain code was bug-free but our =
simulators or data were corrupted. We measured that 2 times out of 3 =
tests failures were not due to our domain code. Worst, we had to fix the =
bugs before going on and we found it 2 to 3 times longer fixing those =
bugs simply because we had no tests to back up our simulators or test =
data!

yes, which is why Cactus reuses container objects and which is why Mock =
Objects are not stubs (in the sense that they do not implement logic but =
externalise it to the test cases).

  I didnt express myself correctly saying that we encountered =
limitations with our in-container testing strategy. It was rather our =
test strategy as a whole that proved to be poor. Mock objects solved a =
lot of our problems with its capacity to do really fine grained unit =
tests. We rewrote some of the critical tests that caused problems (DBs, =
JMS, Crypto) and now those tests run correclty 100% of the time. We =
still use Cactus, but at a much higher level, to test our use cases. So =
its like integration tests on a use case by use case basis.

  To focus on the discussion Mock vs In-container, in our opinion one of =
the big advantage of mock objects is the capacity to write very focused =
unit tests and sometimes testing pieces of code it would be difficult to =
test otherwise. The tests can run very quickly and independently (most =
of the time) of external settings=20

agreed ...

  ensuring that once they have passed, we dont have to worry about them =
anymore.=20

well, not completely true, you're still not sure that your code will run =
when deployed and interacting with other domain objects and with the =
containers.

  A side effect of using mock objects was that we ended up writing =
better code, thought more in terns of interfaces, removing unecessary =
dependencies between domain objects and singletons for instance.

100% true. I'm just realising that if you understand this, the answer I =
have given in your other email is probably something well known to you. =
I apologise if this is the case ... :)


  On the other hand, using mo proved to be challenging and it still is. =
It took time to understand and use them properly, then it took time to =
write our own properly (respecting the concepts). We also had to change =
parts of our code to introduce the mock objects, adding factories and =
registry so that domain objects implementations can be replaced by mock =
objects implementations during testing. But once they are written, like =
tests, we can leverage mo on subsequent projects.

it is ok to refactor code so that it is easier to be tested. However, =
you should be careful that you do not introduce new things that will =
change too radically your architecture (like decoupling all objects by =
providing a new communication layer between them, that would affect =
performances). If it is what you need for your application then fine, =
however, if it is just needed because of the tests and not needed for =
production, then it is bad ...

  I would imagine that If you participate in both Catcus and MO, you =
also feel that both approaches are complementary :-)

indeed.

  I will be very busy in the next weeks or so on my project, but I can =
still spare some free time to help on the project. Let me think of the =
best way for me to help.

  Regards,
  Vincent

-Vincent

  ----- Original Message -----=20
    From: Vincent Massol=20
    To: Vincent Tenc=E9 ; moc...@li...=20
    Sent: Thursday, October 18, 2001 4:36 AM
    Subject: Re: [Mockobjects-java-dev] Interested in participating


    Hi Vince,

      ----- Original Message -----=20
      From: Vincent Tenc=E9=20
      To: moc...@li...=20
      Sent: Thursday, October 18, 2001 3:36 AM
      Subject: [Mockobjects-java-dev] Interested in participating


      Hi all,

      First of all thanks for the framework, it is of unvaluable use. =
Great work.=20

    thanks :)

      We have been developping servlets and were doing in-container =
testing up to recently. The limitations that we encountered forced us to =
look for a different testing=20

    I would be interested in hearing these as I'm participating to both =
Cactus (in-container testing) and Mock Objects. I have my own ideas on =
the pros and cons of each but would be very interested to hear from =
someone who has really used both approaches, on a real project.

      approach until we read about mock objects. We used the mock =
objects servlet package, extended it for our own use, measured the =
benefits then decided to develop a mock objects JMS package (it works =
fine and serves us well). Now we plan to convert all our DAO unit tests =
to using mock objects.

      Like with JUnit tests, since we tried mock objects, we have a hard =
time doing our tests any different way. So if you guys would accept some =
help we would be pleased to participate in the effort, being addicted =
mock objects users ourselves!

    that's really great to hear ! :o) Welcome aboard.  I fear we haven't =
had as much time as we would like so far and any help is welcome. Have a =
look at CVS and choose what you'd like to do. Unfortunately we've not =
made a todo list yet. Maybe you could propose items for the todo list =
and volunteer for some of them ? These are the different areas where you =
could help :
    - improve existing code and especially code that is not finished. =
The servlet mocks for example are far from being finished.
    - improve build process
    - improve web site documentation
    - help answer to mailing-lists posts
    - promote mock objects around you (I'm sure you're already doing =
that !)
    - anything else you might think of

      Regards,
      Vincent Tenc=E9


    -Vincent

    --
    Vincent Massol, vm...@oc...
    OCTO Technology, www.octo.com
    Information System Architecture Consulting