Difference between revisions of "Property Based Developer Testing"

From CitconWiki
Jump to navigationJump to search
 
Line 2: Line 2:
  
 
Proposed by [[Paul Holser]]
 
Proposed by [[Paul Holser]]
 +
 +
* Amounts to adding "for-all" style assertions about a function to some "there-exists" style tests.
 +
* Works best on already-TDD'ed code. TDD builds up designs example by example. Hard to see the "for-all" statements without data point to triangulate from.
 +
* Agitar does something similar -- execute code using lots of different kinds of inputs, possibly deriving interesting data points by inspecting the test subject itself...
 +
* Works well on already "math-y" domains
 +
* Drives you, if you're paying attention, away from Primitive Obsession and modeling things like SKUs, Prices, SSNs, etc. as first-class concepts. Otherwise generators miss too much, or try to create invalid things.
  
 
= Literature =
 
= Literature =

Latest revision as of 08:52, 26 August 2013

Session at CITCONNA2013Sessions

Proposed by Paul Holser

  • Amounts to adding "for-all" style assertions about a function to some "there-exists" style tests.
  • Works best on already-TDD'ed code. TDD builds up designs example by example. Hard to see the "for-all" statements without data point to triangulate from.
  • Agitar does something similar -- execute code using lots of different kinds of inputs, possibly deriving interesting data points by inspecting the test subject itself...
  • Works well on already "math-y" domains
  • Drives you, if you're paying attention, away from Primitive Obsession and modeling things like SKUs, Prices, SSNs, etc. as first-class concepts. Otherwise generators miss too much, or try to create invalid things.

Literature

Tooling:

Java

Scala

Python

Ruby

Haskell

Erlang