• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Mock GenericDao for Unit Testing

 
Greenhorn
Posts: 16
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to develop a Mock of My GenericDao class. For example for the following method of my GenericDao class:




I have the following Mock:



How can I mock the following method of my GenericDao?? :



Something inside this:

 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't understand the question. What is the connection between getList() and getListByPage()?
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll take it a step beyond where Jeanne is going: I've seen things like this before and if you're going where I think you're going with this GenericDao thing, while you think that it will simplify things for you, it will only lead you down the road to over-complexity and sorrow.

Here's my suggestion:
  • Use interfaces to define the contracts for your DAO. If you read Eric Evans' book "Domain Driven Design", a DAO is really just another type of service: an infrastructure service to access a Repository.
  • Using interfaces to define the contract for your DAO/RepositoryService allows you to use mocking frameworks like Mokito - learn how to use those, they are full of goodness and joy

  • When it comes to DAOs, it's better to be very specific about what they do, rather than trying to make some kind of "generic" thing that you can somehow configure. There is always going to be some variation that you didn't think of before that will cause you to make changes to the "generic" DAO that is very specific to each newly-thought-of case. Very ironic. There are frameworks like Spring and Hibernate that provide a lot of ready-to-use classes that will simplify things for you at the "plumbing" level of code so that you can concentrate on writing the business logic instead. Learn how to use frameworks like Spring and ORM frameworks like Hibernate to simplify your code. A lot of the heavy lifting has already been done for you. They are also full of goodness and joy, when used properly.

    If my read on your direction is wrong and you're only calling it GenericDao in the same sense as say, FooDao, the suggestions 1 and 2 above are still in effect. Additional thought: paging is a presentation concern and should be separated from the concern of getting data out of a repository. As such, a method like getListByPage creates a code smell in a DAO class. See this article http://thinkbeforecoding.com/post/2009/04/08/Back-on-Repositories-and-Paging-Introducing-reporting for more.
     
    Hang a left on main. Then read this tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic