A critique of Abelson and Sussman or why calculating is better than scheming
ACM SIGPLAN Notices
Algebraic specification
Handbook of theoretical computer science (vol. B)
QuickCheck: a lightweight tool for random testing of Haskell programs
ICFP '00 Proceedings of the fifth ACM SIGPLAN international conference on Functional programming
Data Abstraction, Implementation, Specification, and Testing
ACM Transactions on Programming Languages and Systems (TOPLAS)
The Definition of Standard ML
Purely Functional Data Structures
Purely Functional Data Structures
Testing monadic code with QuickCheck
Proceedings of the 2002 ACM SIGPLAN workshop on Haskell
Introduction to Functional Programming
Introduction to Functional Programming
Programming with abstract data types
Proceedings of the ACM SIGPLAN symposium on Very high level languages
Proceedings of the tenth ACM SIGPLAN international conference on Functional programming
Testing telecoms software with quviq QuickCheck
Proceedings of the 2006 ACM SIGPLAN workshop on Erlang
Haskell '07 Proceedings of the ACM SIGPLAN workshop on Haskell workshop
Testing Erlang data types with quviq quickcheck
Proceedings of the 7th ACM SIGPLAN workshop on ERLANG
GAST: generic automated software testing
IFL'02 Proceedings of the 14th international conference on Implementation of functional languages
Testing data types implementations from algebraic specifications
Formal methods and testing
Proceedings of the 2012 Haskell Symposium
Model based testing with logical properties versus state machines
IFL'11 Proceedings of the 23rd international conference on Implementation and Application of Functional Languages
Hi-index | 0.00 |
Algebraic specification, equational reasoning, and property-based random testing provide functional programmers with a powerful yet reasonably lightweight framework for reasoning about abstract datatypes and assuring the quality of their concrete implementations. However, as it turns out, naïvely implementing property-based random testing for purely functional abstract datatypes is prone to subtle errors and may well leave unaware practitioners with a false sense of security about their datatype implementations. In this paper, we pinpoint one particular pitfall, namely overlooking the need to take into account the invariance of datatype operations under an implied equivalence relation on concreate datatype values, and discuss how to systematically avoid it. Presented in the context of a concrete case study, the proposed technique generalises nicely into a common design principle for engineering random tests of purely functional datastructures.