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

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

Expand Messages
  • 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 1 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 2 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 3 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.