Skip to main content


Showing posts from September, 2014

Hazelcast's MapLoader pitfalls

One of the core data structures provided by Hazelcast is IMap<K, V> extending java.util.concurrent.ConcurrentMap - which is basically a distributed map, often used as cache. You can configure such map to use custom MapLoader<K, V> - piece of Java code that will be asked every time you try to .get() something from that map (by key) which is not yet there. This is especially useful when you use IMap as a distributed in-memory cache - if client code asks for something that wasn't cached yet, Hazelcast will transparently execute your MapLoader.load(key) : public interface MapLoader<K, V> { V load(K key); Map<K, V> loadAll(Collection<K> keys); Set<K> loadAllKeys(); } The remaining two methods are used during startup to optionally warm-up cache by loading pre-defined set of keys. Your custom MapLoader can reach out to (No)SQL database, web-service, file-system, you name it. Working with such a cache is much more convenient because

Property-based testing with ScalaCheck - custom generators

In the previous article we examined how Spock can be used to implement property-based testing. One of the " hello, world " examples of property-based testing is making sure absolute value of arbitrary integer is always non-negative. We did that one as well. However our test didn't discover very important edge case. See for yourself, this time with ScalaCheck and ScalaTest : import org.scalatest.FunSuite import org.scalatest.prop.Checkers class AbsSuite extends FunSuite with Checkers { test("absolute value should not be negative") { check((somInt: Int) => { somInt.abs >= 0 }) } } ...or with a different syntax: import org.scalatest.FunSuite import org.scalatest.matchers.ShouldMatchers import org.scalatest.prop.{GeneratorDrivenPropertyChecks, Checkers} class AbsSuite extends FunSuite with GeneratorDrivenPropertyChecks with ShouldMatchers{ test("absolute value should not be negative") { forA

Property-based testing with Spock

Property based testing is an alternative approach to testing, complementing example based testing . The latter is what we've been doing all our lives: exercising production code against "examples" - inputs we think are representative. Picking these examples is an art on its own: "ordinary" inputs, edge cases, malformed inputs, etc. But why are we limiting ourselves to just few examples? Why not test hundreds, millions... ALL inputs? There are at least two difficulties with that approach: Scale. A pure function taking just one int input would require 4 billion tests. This means few hundred gigabytes of test source code and several months of execution time. Square it if a function takes two int s. For String it practically goes to infinity. Assume we have these tests, executed on a quantum computer or something. How do you know the expected result for each particular input? You either enter it by hand (good luck) or generate expected output. By generate