powermock unit testing

On PowerMock abuse

Still working on my legacy application, and still trying to improve unit tests. This week, I noticed how much PowerMock was used throughout the tests, to mock either static or private methods. In one specific package, removing it improved tests execution time by one order of magnitude (from around 20 seconds to 2). That’s clearly abuse: I saw three main reasons of using PowerMock. Lack of knowledge of the API There probably must have been good reasons, but some of PowerMock uses could

mockito unit testing

Initializing your Mockito mocks

Maintenance projects are not fun compared to greenfield projects, but they sure provide most of the meat for this blog. This week saw me not checking the production code but the tests. What you see in tests reveals much of how the production code itself is written. And it’s a way to change things for the better, with less risks. At first, I only wanted to remove as much PowerMock uses as possible. Then I found out most Mockito spies were not necessary. Then I found out that Mockito mocks

integration testing test unit testing

Integration tests from the trenches

This post is the written form of one of my submission for Devoxx France 2013. As it was only chosen as backup, I lacked the necessary motivation to prepare it. The subject is important though, so I finally decided to write it down. In 2013, if you’re a standard developer, it is practically a given that you test your code. Whether you’re a practicioner of TDD or just create them afterwards, most realize a robust automated test harness is not optional but mandatory. Unit Test vs Int

mock powermock testng unit testing

PowerMock, features and use-cases

Even if you don't like it, your job sometimes requires you to maintain legacy applications. It happened to me (fortunately rarely), and the first thing I look for before writing as much as a single character in a legacy codebase is a unit testing harness. Most of the time, I tend to focus on the code coverage of the part of the application I need to change, and try to improve it as much as possible, even in the total lack of unit tests.

unit testing user interface

Dependency Injection on GUI components

For some, it goes without saying but a recent communication made me wonder about the dangers of implicitness in it. In my book http://www.packtpub.com/learning-vaadin-rias/book[Learning Vaadin^], I showed how to integrate the Vaadin web framework with the Spring DI framework: in order to make my point, I wired Vaadin UI components together. I did this because I didn't want to go into the intricacies of creating a service layer. I had some comments questioning whether injecting UI components was r

unit testing

Shoud you change your design for testing purposes?

As Dependency Injection frameworks go, the standard is currently CDI. When switching from Spring, one has to consider the following problem: how do you unit test your injected classes? In Spring, DI is achieved through either constructor injection or setter injection. Both allow for simple unit testing by providing the dependencies and calling either the constructor or the desired setter. Now, how do you unit test the following code, which uses field injection: public class MyMainClass { @

factoryBean mockito proxy spring spy stub stubbing unit testing

Mockito' spy() method and Spring

Mockito is a mocking framework (see Two different mocking approaches) that is an offshoot of EasyMock. Whatever the mocking framework one uses, a common feature is the ability to mock interfaces, through the JDK Proxy class. This is well and nice, but one has to explicitly mock every method that one wants to use in the course of the test. What if I want to mock an already existing implementation, with some methods providing behaviours that suit me ? Today, I ran across this case: I had a legacy