Clojure: Testing The Creation Of A Partial Function

Posted 10 days back at Jay Fields Thoughts

I recently refactored some code that takes longs from two different sources to compute one value. The code originally stored the longs and called a function when all of the data arrived. The refactored version partials the data while it's incomplete and executes the partial'd function when all of the data is available. Below is a contrived example of what I'm taking about.

Let's pretend we need a function that will allow us to check whether or not another drink would make us legally drunk in New York City.

The code below stores the current bac and uses the value when legally-drunk? is called.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/src/clojure/original.clj"></script> The following (passing) tests demonstrate that everything works as expected.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/test/expectations/original_expectations.clj"></script> This code works without issue, but can also be refactored to store a partial'd function instead of the bac value. Why you would want to do such a thing is outside of the scope of this post, so we'll just assume this is a good refactoring. The code below no longer stores the bac value, and instead stores the pure-legally-drunk? function partial'd with the bac value.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/src/clojure/refactored.clj"></script> Two of the three of the tests don't change; however, the test that was verifying the state is now broken.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/test/expectations/refactored_expectations.clj"></script> note: The test output has been trimmed and reformatted to avoid horizontal scrolling.

In the output you can see that the test is failing as you'd expect, due to the change in what we're storing. What's broken is obvious, but there's not an obvious solution. Assuming you still want this state based test, how do you verify that you've partial'd the right function with the right value?

The solution is simple, but a bit tricky. As long as you don't find the redef too magical, the following solution allows you to easily verify the function that's being partial'd as well as the arguments.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/test/expectations/refactored_passing_expectations.clj"></script> Those tests all pass, and should provide security that the legally-drunk? and update-bac functions are sufficiently tested. The pure-legally-drunk? function still needs to be tested, but that should be easy since it's a pure function.

Would you want this kind of test? I think that becomes a matter of context and personal preference. Given the various paths through the code the following tests should provide complete coverage.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/test/expectations/high_level_expectations.clj"></script> The above tests make no assumptions about the implementation - they actually pass whether you :use the 'original namespace or the 'refactored namespace. Conversely, the following tests verify each function in isolation and a few of them are very much tied to the implementation.

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/test/expectations/unit_level_expectations.clj"></script> Both sets of tests would give me confidence that the code works as expected, so choosing which tests to use would become a matter of maintenance cost. I don't think there's anything special about these examples; I think they offer the traditional trade-offs between higher and lower level tests. A specific trade-off that stands out to me is identifying defect localization versus having to update the test when you update the code.

As I mentioned previously, the high-level-expectations work for both the 'original and the 'refactored namespaces. Being able to change the implementation without having to change the test is obviously an advantage of the high level tests. However, when things go wrong, the lower level tests provide better feedback for targeting the issue.

The following code is exactly the same as the code in refactored.clj, except it has a 1 character typo. (it's not necessary to spot the typo, the test output below will show you want it is)

<script src="http://gist-it.appspot.com/github/jaycfields/Clojure--Testing-The-Creation-Of-A-Partial-Function/blob/master/src/clojure/refactored_with_typo.clj"></script> The high level tests give us the following feedback.

failure in (high_level_expectations.clj:14) : expectations.high-level-expectations
(expect
 true
 (with-redefs
  [state (atom {})]
  (update-bac 0.01)
  (legally-drunk? 0.07)))

           expected: true 
                was: false

There's not much in that failure report to point us in the right direction. The unit-level-expectations provide significantly more information, and the details that should make it immediately obvious where the typo is.

failure in (unit_level_expectations.clj:8) : expectations.unit-level-expectations
(expect
 {:legally-drunk?* [pure-legally-drunk? 0.04]}
 (with-redefs [state (atom {}) partial vector] (update-bac 0.04)))

           expected: {:legally-drunk?* [#<refactored_with_typo$pure_legally_drunk_qmark_@621bedb0> 0.04]} 
                was: {:legally-drunk?** [#<refactored_with_typo$pure_legally_drunk_qmark_@621bedb0> 0.04]}
 
           :legally-drunk?** with val [#<refactored_with_typo$pure_legally_drunk_qmark_@621bedb0> 0.04] 
                             is in actual, but not in expected
           :legally-drunk?* with val [#<refactored_with_typo$pure_legally_drunk_qmark_@621bedb0> 0.04] 
                            is in expected, but not in actual

The above output points us directly to the extra asterisk in update-bac that caused the failure.

Still, I couldn't honestly tell you which of the above tests that I prefer. This specific example provides a situation where I think you could convincingly argue for either set of tests. However, as the code evolved I would likely choose one path or the other based on:

• how much 'setup' is required for always using high-level tests?
• how hard is it to guarantee integration using primarily unit-level tests?

In our examples the high level tests require redef'ing one bit of state. If that grew to a few pieces of state and/or a large increase in the complexity of the state, then I may be forced to move towards more unit-level tests. A rule of thumb I use: If a significant amount of the code within a test is setting up the test context, there's probably a smaller function and a set of associated tests waiting to be extracted.

By definition, the unit-level tests don't test the integration of the various functions. When I'm using unit-level tests, I'll often test the various code paths at the unit level and then have a happy-path high-level test that verifies integration of the various functions. My desire to have more high-level tests increases as the integration complexity increases, and at some point it makes sense to simply convert all of the tests to high-level tests.

If you constantly re-evaluate which tests will be more appropriate and switch when necessary, you'll definitely come out ahead in the long run.

Episode 48: Barista imposter syndrome

Posted 11 days back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Episode 48: Barista imposter syndrome:

In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Jon Larkowski, closet hippie and developer at CareZone. Ben and Jon discuss being a closet hippie, transitioning from consulting to working on a startup/product team, ping-pong, paying attention to your habits and improving to your life, meditation, firewalling your attention, fostering a startup culture, imposter syndrome, podcasting, coffee, code review, guitar, and much more.

• Episode Notes and Links
• Subscribe via iTunes
• Subscribe via RSS
• Direct Download

Strollin'

Posted 13 days back at Mike Clark

Ruby Science: You down with OCP?

Posted 14 days back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Yeah, you know me.

We just pushed the latest update to Ruby Science, including five new chapters. Previous purchasers and Prime subscribers can grab the update on Learn.

New chapters this week discuss:

• Using the Single Responsibility Principle to create readable, reusable classes.
• Applying the Open/Closed Principle to reduce churn and prevent breakage while keeping objects easy to change.
• Applying the Dependency Inversion Principle to create flexible, reusable objects.
• Using the Law of Demeter to prevent application dependencies from becoming a tangled mess.
• Choosing Composition Over Inheritance to make simpler, more flexible software.

The book is a work in progress, and is currently 230 pages long. Your purchase gets you access to the current release of the book, all future updates, and the companion example application.

Get your copy of Ruby Science today.

Now Available For Free With Learn Prime

We recently launched a service to help subscribers become better developers, called Learn Prime.

For just $99/month, you get ongoing access to everything we teach, including books like Ruby Science. You’ll even get access to all our in-person and online workshops. Get access to exclusive subscriber content and use the forum to ask thoughtbot your toughest Ruby, Rails, and refactoring questions.

Subscribe now.

Written by Joe Ferris.

Reducing Churn in Subscription Services

Posted 14 days back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

You’ve probably heard by now that we’ve launched a learning community for passionate Rails developers called Prime.

Since Prime is a subscription service, one of metrics we’re interested in is churn, defined as the percentage of total customers who cancel. Over the last 30 days, Prime’s churn has been 18%.

Estimates of what a “good” churn is vary. One broad survey of SaaS companies with less than $10M in revenues showed a median churn of 20%, while some blog posts insist that anything over 8% should be panic-inducing.

To gain some perspective and get advice, I reached out to a friend and former podcast guest, Brennan Dunn.

Brennan is creator of a successful SaaS app called Planscope, author of several excellent ebooks, and overall “good at making money on the internet” kind of guy.

Below, you’ll find a recording of our 40-minute chat. In it, we dig into Prime’s current stats (including subscriber count and revenue growth), and Brennan’s suggestions for how to improve the site. What started off as recommendations for reducing churn turned into a broader discussion of how to position the entire service. If you run a subscription service of your own, you’ll likely learn a thing or two from Brennan’s battle-tested advice.

Check it out!

Direct download.

If our discussion left you with further questions for Brennan, leave them in the comments below and perhaps we can convince him to respond.

New screencast: Improving Performance for Real-time Requests

Posted 15 days back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

We’re pleased to announce our newest screencast video on Learn, Improving Performance for Real-time Requests.

This video, with thoughtbot CTO Joe Ferris, shows you how to tune performance using a real world example. Starting with an action that takes 3 seconds to respond and performs over 1600 database queries, Joe is able to reduce response time to 300ms and drop database usage to just 5 queries.

This video specifically focuses on what Joe calls ‘real-time requests’. That is, requests that must return all of their data to the user in the request-response cycle, without relying on background jobs or persistent caching.

Prime subscribers get this new video included with their monthly subscription. You can also purchase it individually for $15 or for your whole company for just $49.

Slow Rails applications annoy users and lead to lost revenue. Achieve a competitive advantage by making your application UNCOMFORTABLY FAST. Learn how today!

Announcing Learn for iPad

Posted 16 days back at GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS - Home

Today we released a new version of Learn to the App Store, which adds the most frequently requested feature, iPad support!

Additionally, this release includes several improvements on both iPhone and iPad. Resources that are available as iBooks can now be viewed in the iBook store, better navigation controls have been added to web resources, and check-offs are now accompanied by sweet audio feedback.

If you would like to add resources to the Trail Maps that the app uses, please contribute to the open source repository on GitHub.

Learn is available for free on the App Store, so try it out today!

Written by Diana Zmuda.

Phusion Passenger 4.0.2 released

Posted 17 days back at Phusion Corporate Blog

Phusion Passenger is software that deploys Ruby and Python web apps, by integrating into Apache and Nginx and turning them into a fully-featured application server. It is very fast, stable and robust and thus used by the likes of New York Times, AirBnB, Symantec, Pixar, etc. It comes with many features that makes your life easier and your application perform better.

We are releasing an emergency release in response to a recently discovered remote code execution vulnerability in Nginx (CVE-2013-2028). Many versions of Nginx 1.3, as well as Nginx 1.4.0, are affected. Phusion Passenger 4.0.2 installs Nginx 1.4.1 by default. There are no other code changes.

Installing 4.0.2

Quick install/upgrade

Phusion Passenger Enterprise users can download the Enterprise version of 4.0.2 from the Customer Area.

Open source users can install the open source version of 4.0.2 with the following commands:

gem install passenger
passenger-install-apache2-module
passenger-install-nginx-module

You can also download the tarball at Google Code. We strongly encourage you to cryptographically verify files after downloading them.

In-depth instructions

In-depth installation and upgrade instructions can be found in the Installation section of the documentation. The documentation has been updated to cover 4.0 changes, including Enterprise features. You can view them online here:

• Apache manual
• Nginx manual

Final

If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.