Imagine that you’re writing a web service. It is implemented with a bunch of classes. Pretend this circle represents your service, and the shapes inside it are classes. The way I learned test-driven development[1], we wrote itty-bitty tests around every itty-bitty method in each class. Then maybe a few acceptance tests around the outside. This …
Why replace our carefully chosen, exactingly specified example-based tests with properties, when properties are harder to write and less specific? link to YouTube Video from Midwest.io 2014 Related code: https://github.com/jessitron/scalacheck-prisoners-dilemma
When testing akka code, I want to make sure a particular actor gets shut down within a time limit. I used to do it like this: Thread.sleep(2.seconds) assertTrue(actorRef.isTerminated()) That isTerminated method is deprecated since Akka 2.2, and good thing too, since my test was wasting everyone’s time. Today I’m doing this instead: import akka.testkit.TestProbeval probe = …
Getting a test to fail is one thing; getting it to express why it failed is another.Clojure.test provides an assertion macro: is (deftest “my-function” (testing “some requirement” (is (something-that-evaluates-to-bool (arg1) (arg2)) “Message to print when it’s false”))) When this assertion fails, in addition to the message, “expected” and “actual” results print. The is macro tries to …
Restarts are awesome when stuff fails and you want it to work. Akka does this by default for every actor, and that’s great in production. In testing, we’re looking for failure. We want to see it, not hide it. In testing, it’s sneaky of Akka to restart our whole actor hierarchy when it barfs. Change …
Property-based testing and functional programming are friends, because they’re both motivated by Reasoning About Code. Functional programming is about keeping your functions data-in, data-out so that you can reason about them. Property-based testing is about expressing the conclusions of that reasoning as properties, then showing that they’re (probably) true by testing them with hundreds of …
When code doesn’t behave the same way every time, it’s tough to unit test it. Sometimes we want a random element in the code. For instance, maybe we want an error report now and then when a certain problem occurs, but every time would be too much. How can we test that something occurs 10% …
Read moreA trick for deterministic testing of random behavior
Writing tests first forces you to think about the problem you’re solving. Writing property-based tests forces you to think way harder.— Jessica Kerr (@jessitron) April 25, 2013 What is this property-based thing? Property-based tests make statements about the output of your code based on the input, and these statements are verified for many different possible …
Today in Unit Testing, an evil framework class hid my important return value away in a private field. Groovy to the rescue! So far, all our code and tests are in Java. It took only two lines in build.gradle, as specified in the gradle documentation, and poof. I put my little test class in src/test/groovy/package/structure, …