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