Writing boilerplate code is a royal pain. Generic programming promises to alleviate this pain by allowing the programmer to write a generic "recipe" for boilerplate code, and use that recipe in many places. In earlier work we introduced the "Scrap your boilerplate " approach to generic programming, which cunningly exploits Haskell's existing type-class mechanism to support generic transformations and queries.

Abstract. Given a grammar (or other sorts of meta-data), one can trivially derive combinatorially exhaustive test-data sets up to a specified depth. Without further efforts, such test-data sets would be huge at the least and explosive most of the time. Fortunately, scenarios of grammar-based testing tend to admit nonexplosive approximations of naive combinatorial coverage. In this paper, we describe the notion of controllable combinatorial coverage and a corresponding algorithm for test-data generation. The approach is based on a suite of control mechanisms to be used for the characterization of test-data sets as well-defined and understandable approximations of full combinatorial coverage. The approach has been implemented in the C#-based test-data generator Geno, which has been successfully used in projects that required differential testing, stress testing and conformance testing of grammar-driven functionality. 1

The behaviour of systems is determined by their implementation in some form of source code. While behaviour itself is complex and its detailed semantics are hard to describe by means of lower level than a programming or specification language, the structure of dynamic input/output behaviour is limited by the system logic and fixed during operation in most cases. Certain aspects of system behavior can be captured by regular expressions that define the possible input/output behaviors of the system. A more refined kind of regular expression can be constructed that does not only represent I/O interleaving but also the location and type of every particular I/O event. This article describes the generation of such expressions and shows how they can be used to aid classic verification by testing, as well as in a criterion to assess the quality of given test case sets. Additionally, a method is sketched to falsify the behavioural identity of systems using the presented approach. Finally, a tool to apply the presented ideas in verification practice on MC68HC705J1A microcontroller programs is overviewed. 1. A look at system behaviour Any (computational) system, may it be a program or a piece of hardware, can be seen as a processing unit accepting certain inputs at certain times of operation and producing outputs at certain points in time. These input/output events can be controlled and monitored from the outside of the system. The internal mechanisms that process inputs and calculate outputs remain invisible in this black box view. It is the basis of classic simulative verification.