• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

testing private method

 
Bartender
Posts: 1111
Eclipse IDE Oracle VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i have 2 methods:



so the only logic is the private mapper method, i have 3 options for testing this which is better
1) make the method protected
2) make it a mapper class
3) spy on the variables sent to the diaryService.update method.

i suppose there is option 4, refactor the code to remove this whole problem, but I have no idea how that could be done.
 
Sheriff
Posts: 15784
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
how about an update entry builder with a buildFrom(DiaryEntry) method? You can test that pretty cleanly. I would start with a builder class that is package private in scope too.
 
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I guess there's also option 5:
- using PowerMockito, mock the constructor calls
- check the calls on the mocks
- call the private method via reflection

Option 6 comes to mind too: make the method package local, and access it that way in your test (given that your test is in the same package)
 
Ranch Hand
Posts: 2908
1
Spring Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I recommend Junilu answer, remember if you're mocking private methods, there is something wrong with your design.

Secondly, if you're already stuck in legacy code base or don't want to touch/alter current code, try Mockito Argument Matcher on m_diaryService.update(update);, if you can mock m_diaryService.
 
Geroen Joris
Greenhorn
Posts: 4
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not talking about mocking, I'm talking about accessing. And I have been in the same situation - after having used "extract method" enough in your IDE to separate the different levels of abstraction.

I do, however, tend to agree with you in this case. The builder is the better option. The private method doesn't seem to contains something that's to be considered private to this class.
 
There's a hole in the bucket, dear Liza, dear Liza, a hole in the bucket, dear liza, a tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic