ad-hockery: /ad·hok'@r·ee/, n.
Gratuitous assumptions... which lead to the appearance of semi-intelligent behavior but are in fact entirely arbitrary. Jargon File

How can test it if I don't know what I'm building yet?

One objection to the practice of TDD I’ve heard from several different people is along the lines of “I don’t know exactly what I’m building at the outset, the code is experimental, so how can I write tests for it?”

Frequently it is the case that you have an idea but don’t know the mechanics of how you’re going to implement it. I find this particularly when I’m writing code that extends a third-party library. You don’t know exactly where the API hooks you’ll need to use are, your understanding of the API is fuzzy and you expect to learn it as you go. So how do you test-drive in that situation?

Read more…

Multiple interface mocks with Spock

Spock’s Mock factory method (as well as factories for the other types of test double; Stub & Spy) accepts a single interface representing the type you need a test double for. But what should you do if you need a test double that implements multiple interfaces?

Read more…

Spock and Hamcrest

Groovy’s power assert and Hamcrest matchers both solve a similar problem – getting decent diagnostic information from an assertion failure. When writing JUnit or Spock tests in Groovy it’s typical to not use Hamcrest matchers as the power assert is so much simpler and just as effective. It’s worth bearing in mind, though that Hamcrest is also for helping clearly express the intent of an assertion. Spock provides support for Hamcrest matchers and I recently ran into a situation where I think it was the right thing to use.

Read more…

Closures and field visibility

I find Groovy Closures can sometimes behave in ways that, once I think about it, make perfect sense but initially seem surprising. One example of this is the fact that closures declared in a parent class cannot “see” private fields of that class when run in the context of a child class.

Read more…

@CompileStatic and polymorphic method dispatch

I’m a big fan of Groovy’s @CompileStatic feature – so much so that I’ve updated the Groovy class template in IntelliJ IDEA to use it by default. I should stress I don’t do this because I believe non-statically compiled Groovy to be slow – it isn’t.

Recently Peter Ledbrook reminded me of one drawback which is that method dispatch is statically bound when using @CompileStatic like it is in Java. This means that the behavior of calling polymorphic methods can change when argument types are not known at compile time.

Read more…

Enabling Groovy’s “invokedynamic” support in Gradle

I posted previously about configuring a Gradle project to ensure that only the indy version of Groovy (that is the variant that supports Java 7’s invokedynamic bytecode instruction) is included in the dependency graph. However, just including that version of the Groovy jar is not enough to make your Groovy code compile in such a way that it uses invokedynamic.

Read more…

Static analysis and strictness

Let me be clear – static analysis tools like Checkstyle and Codenarc are useful tools. But…

I don’t think you should have overly strict enforcement. There is a small class of static analysis rules that are unambiguous – you’re not using that import, that if block doesn’t have braces – but there is a large class of rules that exist in a grey area. Is that method really unused or is it invoked reflectively somewhere? Yes, generally we should declare constants for magic numbers but is it really necessary for the prime seed of a hash code method?

Read more…

Decoupling from the DOM with Angular

One piece of advice you’ll run into pretty soon when working with Angular is that you should never touch the DOM outside of a directive. Especially when test-driving your components this is pretty wise. The great strength of Angular is the declarative way in which the view (HTML) works with the view model (Angular controllers). It’s almost absurd how easy it is to unit test Angular controllers. Controller functions tend to act on $scope properties, trigger or respond to events and all those things are straightforward to replicate in unit tests.

Read more…

Unit testing Angular directives that use controller and templateUrl

I spent an hour or so this morning figuring out how to unit test an Angular directive that uses a controller and a template loaded from a file (as opposed to inline). There’s a useful example in the ng-directive-testing repository but I thought a quick summary would be useful (as much to remind me the next time I have to do it as anything). Also the examples there test by interacting with DOM elements rather than directly with the directive’s scope.

Read more…

Web Statistics