Let’s get the formality out of the way – what is property based testing
In the very narrow definition, a property based test is comparing and verifying that a program’s output complies with a rule (property), rather than a specific value.
That being said, add this to the mix (Taken from scalatest.org):
“…a property is a high-level specification of behavior that should hold for a range of data points”.
Translation
Property based testing involves testing your code’s output against one (or more) constraints, for one (or more) input values.
In real life
Property based testing is usually used by running multiple, randomized (or otherwise entered by the test developer) input values, and matching the output values to a set of business rules.
Why do I need this in my life?
- All odd numbers are prime – Random data is (sometimes) smarter than you. Each test run gives you multiple values, that to some degree, were never used before. Some of them are exactly the secret key needed to break the code.
- Real world data is your enemy in production, but your friend in testing – Dumping a load of production derived input values tests your code against the threats that it is expected to meet in real life (see here).
- Unknown unknowns – What you think is wrong with the code (known) should be fixed on the spot. Areas that may hold issues (unknowns) should be tested specifically. Dangerous areas that you don’t know that you don’t know about (unknown unknowns) will not be encountered unless you cast a very wide net, spanning more than you can see. Combining a multitude of input values with many constraints will help you stumble upon them.
- “The only doctor that could have saved me was me” – Sometimes, producing the specific expected value is too resource costly, or only possible using the very same code you are trying to test (nullifying the effort).
Recent Comments