Apache Wicket is a populair web framework. There are a many reasons why I like to use Wicket, for instance: it offers a great mark-up/logic separation and using Wicket it’s very easy to implement AJAX functionality without writing one line of Javascript.
To provide you with simple and short tips and tricks for Wicket I write this series of blogs. In this first blog of the series I will show you how to create a download link in several ways.
NOTE: version 7 of WebStorm already comes with built-in Karma support.
However IntelliJ IDEA 12 users will have to wait for v. 13, making this article still relevant for them.
Recently I started using the Karma (previously called Testacular) test runner for JavaScript, as an alternative for the “Jasmine Maven Plugin”. The primary reason for switching is that Karma uses actual browsers (like Chrome, Firefox, Safari and even IE) to execute the tests instead of the emulated Mozilla Rhino JavaScript engine. To increase productivity I wondered if I could also integrate Karma into WebStorm / IDEA. Currently WebStorm doesn't offer out of the box support the Karma test runner. However it does support executing any kind of NodeJS application (like Karma). Installing the NodeJS plugin (only needed when using IDEA Ultimate) When using IntelliJ IDEA Ultimate you first have to manually install the NodeJS plugin. To install this plugin:
Arthur Arts wrote an blog post about Using ArgumentCaptor for generic collections with Mockito. With the ArgumentCaptor in Mockito the parameters of a method call to a mock are captured and can be verified with assertions. In Spock we can also get a hold on the arguments that are passed to a method call of a mock and we can write assertions to check the parameters for certain conditions. When we create a mock in Spock and invoke a method on the mock the arguments are matched using the equals() implementation of the argument type. If they are not equal Spock will tell us by showing a message that there are too few invocations of the method call. Let’s show this with an example. First we create some classes we want to test:
package com.jdriven.spock
class ClassUnderTest {
private final Greeting greeting
ClassUnderTest(final Greeting greeting) {
this.greeting = greeting
}
String greeting(final List<Person> people) {
greeting.sayHello(people)
}
}
package com.jdriven.spock
interface Greeting {
String sayHello(final List<Person> people)
}
package com.jdriven.spock
@groovy.transform.Canonical
class Person {
String name
}
NOTE: this post was written for Karma 0.8 which required a manual installation of PhantomJS.
However this blog post is still relevant for installing the NodeJS and NPM pre-requisites.
As of 0.10 both PhantomJS and Chrome will be automatically installed by the launcher plugins.
Installation instructions for Karma 0.10 can be found here (a "Local installation" is preferred).
Furthermore instructions on how to install plugins (introduced as of 0.10) can be found here.
Recently I decided to switch from the “Jasmine Maven Plugin” (using the Mozilla Rhino JavaScript “emulator”) to the Karma (previously called Testacular) test runner. The big advantage of Karma opposed to the “Jasmine Maven Plugin” is that it uses actual browsers (like Chrome, Firefox, Safari and even IE) to execute the tests. This blogpost describes the installation and configuration of Karma on Windows. To install Karma you first need to install NodeJS and its NPM (NodeJS Package Manager). Additionally you could install PhantomJS, a “headless” web-kit browser, to run your JavaScript tests from the command-line without spawning unwanted browser windows. Instead of using PhantomJS as a replacement for testing against real browsers you could use it to run tests on your local development machine while your continuous integration server could then run your tests on “all” relevant browsers.
Albert van Veen wrote a blog post about Using ArgumentMatchers with Mockito. The idea is to let a mocked or stubbed service return a different value based on the argument passed into the service. This is inspired me to write the same sample with Spock. Spock already has built-in mock and stub support, so first of all we don’t need an extra library to support mocking and stubbing. We can easily create a mock or stub with the Mock() and Stub() methods. We will see usage of both in the following examples. In the first example we simply return true or false for ChocolateService.doesCustomerLikesChocolate() in the separate test methods.
import spock.lang.*
public class CandyServiceSpecification extends Specification {
private ChocolateService chocolateService = Mock()
private CandyService candyService = new CandyServiceImpl()
def setup() {
candyService.chocolateService = chocolateService
}
def "Customer Albert really likes chocolate"() {
given:
final Customer customer = new Customer(firstName: 'Albert')
and: 'Mock returns true'
1 * chocolateService.doesCustomerLikesChocolate(customer) >> true
expect: 'Albert likes chocolate'
candyService.getCandiesLikeByCustomer(customer).contains Candy.CHOCOLATE
}
def "Other customer do not like chocolate"() {
given:
final Customer customer = new Customer(firstName: 'Any other firstname')
and: 'Mock returns false'
1 * chocolateService.doesCustomerLikesChocolate(customer) >> false
expect: 'Customer does not like chocolate'
!candyService.getCandiesLikeByCustomer(customer).contains(Candy.CHOCOLATE)
}
}
Say you want to test a method from class which extends some kind of superclass. Sometimes you can be dependent on code in the superclass, which is undesirable in a test. Now actually, the first thing you should consider is to refactor your code, because it’s violating the Single Responsibility design principle: there is more than one reason why your class is subject to change. Another advice is to favor composition over inheritence. In this way you can mock the code you are collaborating with. Having said that, sometimes you run into legacy code you just have to work with and aren’t able to refactor due to circumstances. Here’s a trick I found on Stackoverflow to “mock” a superclass method to do nothing with mockito.
public class BaseController {
public void method() {
validate(); // I don't want to run this!
}
}
public class JDrivenController extends BaseController {
public void method(){
super.method()
load(); // I only want to test this!
}
}
@Test
public void testSave() {
JDrivenController spy = Mockito.spy(new JDrivenController());
// Prevent/stub logic in super.method()
Mockito.doNothing().when((BaseController)spy).validate();
// When
spy.method();
// Then
verify(spy).load();
}
Willem Cheizoo already wrote an blog post about How to test for an exception with JUnit and this inspired me to write the same sample with Spock. In Spock we can use the thrown() method to check for exceptions. We can use it in a then: block of our test.
import spock.lang.*
public class JDrivenServiceSpecification extends Specification {
private JDrivenService service = new JDrivenService()
def "publishArticle throws ArticleNotFoundException() {
when:
service.publishArticle null
then:
final ArticleNotFoundException exception = thrown()
// Alternate syntax: def exception = thrown(ArticleNotFoundException)
exception.message == 'Article not found please provide an article to publish'
}
}
