Entries Tagged 'Testing' ↓

Continuos Integration is the practice of integrating changes from many people as often as possible. Instead of merging changes once a month and spending time handling merge errors you try integrate every day, perhaps even every hour. Each integration is built and tested on a server. If there are build errors or test failures, you [...]

There are a few simple steps to get nice graphic presentations of FindBugs results using Maven.

First, to enable FindBugs reporting in Maven, just add report section to your pom files, something like example below, but of course, you can do your own configuration.

I’m going to guess that most of you know what instrumentation is. In the event that you don’t, instrumentation is a feature in which specific monitoring of the interactions between an application and the system is made possible. Instrumentation also makes it possible to write test cases that interact with the application. The problem with [...]

Test Driven Development, or TDD for short, is a simple software development practice where unit tests, small focused test cases, drive the development forward. This is most easily explained by the Three Rules of TDD that dictate the following:

You are not allowed to write any production code [...]

Background
In PowerMock we’re using a custom classloader to byte-code manipulate classes that are normally not mockable to make them mockable. But when running a test case there may be some cases when the user needs to byte-code manipulate a certain class (X) in the first test method but needs to have the class unmodified in [...]

After having it on our todo list for at least a year we’ve finally managed to integrate PowerMock with TestNG 5.11 as of PowerMock version 1.3.5. This is a big milestone of the project since we’ve now demonstrated that PowerMock is decoupled from both a specific test framework and a specific mock framework. The TestNG [...]

With the new release of PowerMock 1.3 we’ve focused a lot on getting the Mockito support up to par with the EasyMock support allowing mocking of e.g. final classes, static methods and new object construction using a Mockito-like syntax. Below you’ll find some examples of how to use the Mockito extension API, aka PowerMockito. Hopefully [...]

The purpose of Unit Testing is to verify for the developer that a software unit does what it is supposed to and is fit for use. The confidence that the developer gets, gives the developer courage to do other useful practices like Refactoring.
Unit testing is often used to test complex units with one or [...]

As you may already know PowerMock can be used to easily mock static methods which is normally not possible with standard mock frameworks such as EasyMock, JMock or Mockito. All you have to do is to use mockStatic in one of the PowerMock extension API’s as well as telling PowerMock to enable the class for [...]

In JayView 17 we presented a short introduction to PowerMock, a framework that allows you to create automated tests for almost any code in isolation from its environment. In this article we’ll dig a bit deeper into PowerMock and explore the goals and more of its feature set.
Background
PowerMock is intended for developers who want [...]

After a discussion about PowerMock with @olabini on Twitter I felt I had to write a post on testability.
The truth “Autonomous, re-runnable, code-based tests are objectivity good” has created a perceived truth, namely “Testable design is good design”. This assumption is incorrect.
The phrase “testable design” is dependent of two things; the design of the code [...]

With EasyMock it is, in some cases, difficult to set up sufficiently precise expectations for the mocks. This may be because we don’t know in advance with which arguments they get called or how often they get called. Or because the verification, we have to make in the test, involves relating the calls to one mock object to the calls to another mock object or relating calls to mock objects to data returned from the object being tested.

In such cases the solution may be to capture “traces” of the method calls to the mock objects, and then, after having exercised the object being tested, to make the needed verifications using the captured traces.