Formal specification and design
Formal specification and design
Purely functional data structures
Purely functional data structures
QuickCheck: a lightweight tool for random testing of Haskell programs
ICFP '00 Proceedings of the fifth ACM SIGPLAN international conference on Functional programming
Testing monadic code with QuickCheck
ACM SIGPLAN Notices
Testing Concurrent Systems: A Formal Approach
CONCUR '99 Proceedings of the 10th International Conference on Concurrency Theory
Randoop: feedback-directed random testing for Java
Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion
Much ado about two (pearl): a pearl on parallel prefix computation
Proceedings of the 35th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages
Trace-based Reflexive Testing of OO Programs with T2
ICST '08 Proceedings of the 2008 International Conference on Software Testing, Verification, and Validation
Testing Erlang data types with quviq quickcheck
Proceedings of the 7th ACM SIGPLAN workshop on ERLANG
Smallcheck and lazy smallcheck: automatic exhaustive testing for small values
Proceedings of the first ACM SIGPLAN symposium on Haskell
FLOPS'08 Proceedings of the 9th international conference on Functional and logic programming
Jartege: a tool for random generation of unit tests for java classes
QoSA'05 Proceedings of the First international conference on Quality of Software Architectures and Software Quality, and Proceedings of the Second International conference on Software Quality
Testing polymorphic properties
ESOP'10 Proceedings of the 19th European conference on Programming Languages and Systems
Proceedings of the 15th Symposium on Principles and Practice of Declarative Programming
Hi-index | 0.00 |
Model-based testing of single functions is usually based on logical properties as specification. In practice it appears to be rather hard to develop a sufficiently strong set of properties to spot all errors. For model-based testing of state based systems one usually employs a state machine as model and a conformance relation between this specification and the software under test. For (abstract) data types we can use both ways of model-based testing. In this paper we compare the specification effort required to make a model that is able to find issues and the number of tests needed to find issues for some well-known data types. Our examples show that it can be easier to write state based specifications. Moreover, state based testing of data types finds more implementation issues and is very efficient.