• 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

Mockito | Test Nested methods

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I need to test the following scenario if insert or update is called on the DAO Method .Since the DAO class is to be tested I am not mocking DAO class so I can't use verify() of mockito whether insert or update is called or not as it can only be used with the mock object and not the actual object.

Please help

1) DAO Method
 
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you read the last couple of posts from me in this other thread about mocking private methods you'll find an example of an approach that you might find useful.
 
Rancher
Posts: 4801
50
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As I sort of said in that other thread.
Why do you care that it calls "update" or "insert". Surely you care about it doing whatever it is that represents an update or insert?
In other words, you care that it makes the relevant call to whatever your persistence framework is.

I'm really not a fan of testing what methods internal to a class are called by the initiating method in that class. That stuff is (in my experience) very prone to change. You'd be fixing unit tests every time you sneezed.

I know others don't necessarily agree, but I felt like having a grump about it...
 
Tim Cooke
Sheriff
Posts: 5555
326
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave is right, of course.

The aim of the game is for each module of code to have a single responsibility. In your example, your code has the responsibility of making modifications to a database and the responsibility of deciding what type of modification is required to be made. This is why you are trying to stub out half of your class to test a single item.

I would look at extracting the database modification code, the insert() and update() code, into a separate class that is decoupled with an interface. That separates the two responsibilities, which you can easily test in isolation of each other.
 
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 agree with what's been said about testing internal methods: that's a test smell.

Potential smell: if you're hitting the real database, then this should not be run as a unit test. Unit tests should run fast and hitting the database is not fast. This should be run as part of the slower set of integration tests.

Code smell: the name insertOrUpdate indicates a violation of single responsibility. I would at least change that method name to something like save() so that it's clear that the client should not care whether it's an update or insert.

That still leaves you with having to test two paths of execution though. If you expect save() to call either update or insert, then I would set up two integration tests: one to test when an update should be done and another to test when it should do an insert. I would have a utility that gets the count of the rows in the table before the call is made and then get the count of the rows after the call is made and make the appropriate assertion to verify that update or insert happened. This way, you're testing that the intended results are what you have and not really caring which method was called. Don't verify the internal implementation; verify that the results are what was intended. If you test with isolated transactions, it's also easy to roll back the transactions so it doesn't affect other tests. It's slower but that's why you run these types of tests as integration tests, separate from your unit tests.
 
He got surgery to replace his foot with a pig. He said it was because of this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic