Geroen Joris

Greenhorn
+ Follow
since Feb 20, 2013
Cows and Likes
Cows
Total received
1
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Geroen Joris

StackOverflowError, which is quite easy to recreate. Just think of a recursive function which creates a huge stack in the VM, and it'll ultimately crash. I've did it with the Fibonacci sequence, with Integer.MAX_VALUE.

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.
4 years ago
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)
4 years ago
Hi all,

Drawn to this forum by the book of this week, I'd like to ask your opinions on mocking, especially when it comes to constructors and static classes.

Let me explain. I use TDD constantly during the day. That means: I make a new class, and right after creating the class, I start writing the test - what we all do, right? Considering we're using a mixture of EJB and CDI (JavaEE) for the moment, I also start mocking. Now, usually, you just mock your injected instance variables with Mockito. But when you start using API's such as the java.io API, you instantly encounter objects such as File. File has a quite straightforward though irritating API: it'll start creating filehandles and actual files on disk, which is quite annoying for unit tests (we don't want to write to disk, since that would be the target of an integration test, not a unit test). So, enter PowerMockito, which allows me to mock the constructors. And once you start doing that, going overboard is quite easy. I've actually written unit tests which were 3 times as long as the actual code, containing 15+ mocks. I mocked every class, or better yet: every constructor call. The downside was writing a lot of mocking code - the up side is that I could actually test the constructor call, without having to know the internals of the resulting object or its constructor related logic. It even kept the IOExceptions and what not away. Duly noted should be that in the beginning, I started writing "FileGenerators" and stuff like that, to generate an actual file which I could use. But I stopped doing that, since - as I said - that's the target of an integration test, not a unit test.
Same goes for the static classes. I constantly find myself mocking the static calls, since I want to control my unit, not having it rely on a static class which can do stuff I don't really care about in my unit test. Needless to say I've become quite the heavy user of PowerMockito - sometimes to grand dismay of my co-workers.

So I wanted to pose the questions to the author as well as to the forum members: what do you consider boundaries for a unit test (which is actually what this is all about)? Do you mock all constructor calls and static classes, or not? How far would you go in controlling the "environment" for your unit? Or do you rely on the constructors and statics?
4 years ago