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.
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).
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.
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.
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.
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
Stub() methods. We will see usage of both in the following examples.
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. Continue reading
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.