Property Based Testing
Dijkstra's
Program testing can at best show the presence of errors, but never their absence
Author states that
Thus we can expect testing to be the main form of program verification fora long time to come—it is the only practical technique in most cases
The point is made that with a CI process in place you can automate testing in your code base but there is still a dilemma on how many test cases to write.
Do you write one test case or many test cases?
In practice, much time is devoted either to simplifying a failing case by hand, or to debugging and tracing a complex case to understand why it fails. Shrinking failing cases automates the first stage of diagnosis, and makes the step from automated testing to locating a fault very short indeed
Test Case Wisdom
During regular test case scenarios in unit-testing your follow the happy path or normal path
This in turn forms basis for future test cases
By generating test cases you can find bugs faster and more accuracy is what I am gleaning from the paper
It is better to run smaller tests than large tests.
Most errors can be found by a smaller test case.
Developer will jump onto the first failing case
Rerun the test case and start debugging the issue
Test cases generated by hand are time consuming as well
When new test cases can be generated by hand in seconds it helps reduce developer time on trivial edge cases.
TestCheck.js
Generative property testing for JavaScript.
TestCheck.js is a library for generative testing of program properties, ala QuickCheck.
By providing a specification of the JavaScript program in the form of properties
Properties can be tested to remain true for a large number of randomly generated cases.
In the case of a test failure, the smallest possible failing test case is found.
Last updated