Skip to content

Instantly share code, notes, and snippets.

@DRMacIver

DRMacIver/anecdotes.markdown

Last active April 12, 2016 06:13
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save DRMacIver/9d53b6a097d14c93f2b6 to your computer and use it in GitHub Desktop.
Save DRMacIver/9d53b6a097d14c93f2b6 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
anecdotes.markdown

Title: The plural of anecdote is not test suite

Type: About half a talk, with the rest of the time for live demos (assuming the demo gods are kind, if not I'll have some bonus slides to talk through) and questions. Experience suggests that talking on this subject gets a lot of questions.

Duration: 90 minutes

Speaker name: David R. MacIver

Speaker biography:

David is the primary author of Hypothesis, a property-based testing tool for Python whose stated mission is "to drag the world kicking and screaming into a new and terrifying age of high quality software". It's a work in progress. He's also working on Conjecture, whose stated mission is "Port Hypothesis to every programming language". Prior to tilting at windmills, he worked at Google and a series of London startups as a back end data engineer.

Location: Cambridge, England

Description:

A test suite should constrain the behaviour of your program to be as close to correct as possible. The best test suites are a kind of executable specification of your code's behaviour.

Most test suites are instead a series of anecdotes about this thing that happened that one time.

We try to fix this problem by adding more anecdotes, because we don't have the tools to turn our test suites into full specifications.

In property-based testing we work in partnership with the computer: We write the tests but the computer supplies the examples to check them. So instead of writing about that thing that happened we get to specify what should happen for every example we've been provided.

So why don't we do this? Property-based testing tools have existed for years, in the form of property-based testing libraries like QuickCheck. Instead of testing like it's 1989, why don't we test like it's the year 2000? Or maybe even later?

Unfortunately, the tools to do so have been stuck in functional programming land - if you're writing Haskell, Erlang, Scala, Clojure or one of a number of others, your life is great. If you're like the rest of us, not so much. This is what Hypothesis and Conjecture aim to fix.

In this session we'll explore property-based testing in mainstream languages - mostly Python through the medium of Hypothesis, but we'll also look at it in other languages. This will be a mix of high level talk about the whys, some detailed walkthroughs of examples, and a whole bunch of live demos where you can put me on the spot and ask me to test things.

Expected level of participants/audience: Beginner friendly, but intermediate and above will probably get more out of it. Some Python familiarity would be helpful, but there will be examples in a variety of languages (TBD, but most likely Python, Java and C++).

Raw
libraries.markdown

Title: Writing libraries is terrible

Type: Talk

Duration: 15 minutes

Speaker name: David R. MacIver

Speaker biography:

David is the primary author of Hypothesis, a property-based testing tool for Python whose stated mission is "to drag the world kicking and screaming into a new and terrifying age of high quality software". It's a work in progress. He's also working on Conjecture, whose stated mission is "Port Hypothesis to every programming language". Prior to tilting at windmills he worked at Google and a series of London startups as a back end data engineer.

Location: Cambridge, England

Description:

Libraries are great, right? You need to solve a problem, so you just find the library that solves it for you, download it, and use it. Problem solved.

This is a talk about everything that happened prior to that point.

Libraries look like they're made out of code, but what they're mostly made out of is the distilled suffering of their authors. Writing libraries is fun, right up until the point people start using them, at which point you suddenly discover the vast number of requirements that making a useful library puts on you.

I'll go over some of these requirements that I had to find out the hard way. At the end I'll briefly talk about a beautiful fantasy land I sometimes like to retreat to where things aren't quite so terrible, but unfortunately we're not going to get to live there for a while.

This talk will be a bit Python centric because that's where most of my experience lies, but much of my pain will be universally shared by library authors of all languages.

Expected level of participants/audience: No particular requirements. Some familiarity with Python would be useful.

@tommorris
Copy link

  • property based → property-based
  • We write the tests, but → we write the tests but (omit comma, lower-case the W)
  • So instead → Instead
  • Prior to tilting at windmills he worked at Google → Prior to tilting at windmills, he worked at Google (add comma)
  • back end → back-end
  • "why don't we"? Interesting question, but not answered. (The probably answer is QuickCheck is Haskell and most people don't care about Haskell because they aren't going to use it in their everyday life like they would with Python or Java or Ruby or JS etc.)
  • Python centric → Python-centric

@olive42
Copy link

olive42 commented Nov 13, 2015

"what libraries are made out of is the distilled suffering of their authors" is a bit tongue-in-cheek I think, and may not be well received or understood by the audience and/or the program committee. Otherwise, suggested rephrasing: "Libraries look like they're made out of code, but they are actually made out of the distilled suffering of their authors."

Same could be said about the "beautiful fantasy land", but then again, I don't really know what kind of conference this is for :)

@DRMacIver
Copy link
Author

Yes, the entire "Writing libraries is terrible" CFP is generally intended to be a bit tongue in cheek. I'm also unsure how this will be received, but figure it's worth a shot. :-)

@DRMacIver
Copy link
Author

This is now submitted BTW.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment