Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Is Mocking useful in 3 layer arch?

Expand Messages
  • Jay Flowers
    It sounds like the root of your question is can you mock situations where your test subject needs to handle/recover from exceptions. Yes a mock can throw an
    Message 1 of 5 , Jun 30, 2006
    • 0 Attachment
      It sounds like the root of your question is can you mock situations
      where your test subject needs to handle/recover from exceptions. Yes
      a mock can throw an exception that you set it up to throw. This is
      actually easier to test with a mock than with out.

      On 6/30/06, Muhammad Ichsan <ichsan@...> wrote:
      > Dear XP practitioners,
      >
      > I'm new in XP and struglling to implement it in my no XP couch country
      > (I guess). My question is: Is mocking useful in 3 layer architecure?
      > Because while mocking, we don't test behaviour of object passed from
      > data layer to service layer (in my case). For example, we don't know
      > what is the state of hibernate object in service (business) layer.
      > Will it throw SessionClosed exception?
      >
      > For this I use integrated test. Not use mocking. What do you think?
      >
      > Regards
      > Ichsan
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >


      --
      Jay Flowers
      ----------------------------------------------------------------------
      http://jayflowers.com
      ---------------------------------------------------------------------
    • Muhammad Ichsan
      vice ... I know this, but by using fake Dao as collaborator in service layer (service layer testing), I have no idea the behaviour of objects given by the dao.
      Message 2 of 5 , Jul 2, 2006
      • 0 Attachment
        vice

        On 6/30/06, Jay Flowers <jay.flowers@...> wrote:
        > It sounds like the root of your question is can you mock situations
        > where your test subject needs to handle/recover from exceptions. Yes

        I know this, but by using fake Dao as collaborator in service layer
        (service layer testing), I have no idea the behaviour of objects given
        by the dao.

        To be specific, I think I'll tell you the case:

        A have dao (data access object) implementation with hibernate. In
        service layer the dao passes the domain object to be processed.
        Sometimes service methods try to get properties of the domain object
        managed by the hibernate. In some case hibernate may throw exception
        because session has been closed.

        In short, I just want to make sure the behaviour of the hibernate
        object in data layer not throw any exception. This is what I call
        success in service layer.

        Is this problem can be devided into two subproblems:
        - test the service layer no matter the daos are.
        - test the behaviour of hibernate object.

        I think this is gonna be complecated test. I guess.

        > a mock can throw an exception that you set it up to throw. This is
        > actually easier to test with a mock than with out.
      • William Pietri
        Hi, Muhammad. Thanks for dropping by; your questions are good ones. ... If you want to stick with your current architectural patterns, the Hibernate unit tests
        Message 3 of 5 , Jul 3, 2006
        • 0 Attachment
          Hi, Muhammad. Thanks for dropping by; your questions are good ones.

          Muhammad Ichsan wrote:
          > A have dao (data access object) implementation with hibernate. In
          > service layer the dao passes the domain object to be processed.
          > Sometimes service methods try to get properties of the domain object
          > managed by the hibernate. In some case hibernate may throw exception
          > because session has been closed.
          >
          > In short, I just want to make sure the behaviour of the hibernate
          > object in data layer not throw any exception. This is what I call
          > success in service layer.
          >
          > Is this problem can be devided into two subproblems:
          > - test the service layer no matter the daos are.
          > - test the behaviour of hibernate object.
          >
          > I think this is gonna be complecated test. I guess.

          If you want to stick with your current architectural patterns, the
          Hibernate unit tests will have to exercise the object in the same way
          the higher layers will to make sure no exceptions will be thrown.

          However, I'd recommend that you change your approach in a few ways.

          First see if you can keep the Hibernate session open. If we're talking a
          web application here, this means closing the session after you transmit
          the response. Then there's no risk of unexpected exceptions, and keeping
          the session open for a few extra milliseconds is a small price to pay.

          It also sounds like you are implementing a 3-tier architecture in
          layers. In my experience, that often leads to Martin Fowler's "Anemic
          Domain Model" anti-pattern, and it's hugely inefficient. In a multi-tier
          architecture you're obliged to copy your data repeatedly because you're
          crossing JVM boundaries all the time. But if you just turn the tiers
          into layers, you end up with a huge amount of unnecessary copying.

          Instead, consider eliminating the DAO layer, using Hibernate to map your
          domain objects directly to the database, and moving a lot of the service
          layer code into the domain objects themselves. You'll end up with a much
          cleaner model, one that will be easier to test.

          Third, rather than separating things out via mocks, I'd suggest you test
          things together when speed allows it. One way to do that with Hibernate
          is to use an in-RAM database like Hypersonic for most of your tests.
          Another is to make Hibernate itself pluggable: make a thin persistence
          interface, then make a Hibernate implementation and one that just stores
          your "persistent" objects in HashMaps for the duration of the tests.
          Either approach is fast, and either approach lets you easily try all of
          your unit tests against particular databases if you'd like to. Of
          course, you'll still need unit tests for the Hibernate mappings, and I
          prefer to do those against a real database.



          Hoping that helps,

          William
        • Muhammad Ichsan
          ... I agree with this. ... 3 layers not 3 tiers. I think I should use dao since later I can change the implementation of storing object by using alfresco for
          Message 4 of 5 , Jul 4, 2006
          • 0 Attachment
            On 7/3/06, William Pietri <william@...> wrote:
            > However, I'd recommend that you change your approach in a few ways.
            >
            > First see if you can keep the Hibernate session open. If we're talking a
            > web application here, this means closing the session after you transmit
            > the response. Then there's no risk of unexpected exceptions, and keeping
            > the session open for a few extra milliseconds is a small price to pay.

            I agree with this.

            >
            > It also sounds like you are implementing a 3-tier architecture in
            > layers. In my experience, that often leads to Martin Fowler's "Anemic
            > Domain Model" anti-pattern, and it's hugely inefficient. In a multi-tier
            > architecture you're obliged to copy your data repeatedly because you're
            > crossing JVM boundaries all the time. But if you just turn the tiers
            > into layers, you end up with a huge amount of unnecessary copying.

            3 layers not 3 tiers. I think I should use dao since later I can
            change the implementation of storing object by using alfresco for
            instance. But thanks for the suggestion :)

            >
            > Instead, consider eliminating the DAO layer, using Hibernate to map your
            > domain objects directly to the database, and moving a lot of the service
            > layer code into the domain objects themselves. You'll end up with a much
            > cleaner model, one that will be easier to test.
            >
            > Third, rather than separating things out via mocks, I'd suggest you test
            > things together when speed allows it. One way to do that with Hibernate
            > is to use an in-RAM database like Hypersonic for most of your tests.
            > Another is to make Hibernate itself pluggable: make a thin persistence
            > interface, then make a Hibernate implementation and one that just stores
            > your "persistent" objects in HashMaps for the duration of the tests.
            > Either approach is fast, and either approach lets you easily try all of
            > your unit tests against particular databases if you'd like to. Of
            > course, you'll still need unit tests for the Hibernate mappings, and I
            > prefer to do those against a real database.
            >
            > Hoping that helps,
            >
            > William
            >

            Thanks William
          Your message has been successfully submitted and would be delivered to recipients shortly.