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