Grammar-based Testing Revisited

I am about to leave for Southampton (this is from where the Titanic started) for a few days to visit Dr. Bernd Fischer, who also calls himself Fish. (Another fish that is!) The idea is to give a talk and have interaction on the topic of grammar-based testing. In fact, I don't tell you any secret, if I say that Bernd is the expert on code generation, and so I am keen to intensify collaboration on that topic as well.

The talk announcement follows.

Speaker: Ralf Lämmel, Software Languages Team, Universität Koblenz-Landau

Title: Grammar-based Testing Revisited

Slides: [.pdf]

Abstract: Testing grammar-based artifacts has been researched for decades. A classical and enduring motivation for such testing is that grammar-based functionality (such as an interpreter or a compiler) may be formally specified (e.g., by means of an attribute grammar) so that the specification lends itself to test-data generation. The test data, in turn, can be used to test a proper implementation for compliance with the specification. Yet other motivations arise, for example, in the context of DSL design, and, more generally, software language engineering.

Despite all such longstanding and recently renewed interests in grammar-based testing, there is no best practice; there are no standard tools. In this talk, I analyze the current, fragmented, insufficiently automated, predominantly ad-hoc approach. To this end, I survey testing approaches and use cases. Finally, I start infering requirements of a more general approach to grammar-based testing.

This is a good time for revisiting grammar-based testing because some categories of industrial users (e.g., compiler writers, who finally start to use parser generators in products) and several major research communities (such as those working on model-driven engineering and software language engineering) face the need for this sort of testing urgently. Also, there are less obviously related communities who touch upon grammar-based testing needs: think of the grammar-like structures in theorem proving, hardware design, and software-product lines.

Bio: Ralf Lämmel is Professor of Computer Science at University of Koblenz-Landau. In his career, he also served at Microsoft Corp., Free University of Amsterdam, Dutch Center for Mathematics and Computer Science (CWI), and University of Rostock. Ralf Lämmel's speciality is "software language engineering" but he is generally interested in themes that combine software engineering and programming languages. Ralf Lämmel is one of the founding fathers of the international summer school series GTTSE-Generative and Transformational Techniques on Software Engineering and the SLE conference (Software Language
Engineering).

Comments

  1. cvDecember 2, 2010 at 12:48 PM

    This is totally new to me the "grammar-based testing"..anyways please keep sharing ..this was quite interesting!


    PROFESSOR CV Template

    ReplyDelete

Post a Comment

Popular posts from this blog

SWI-Prolog's Java Interface JPL

I would like to mix Java and Prolog code on a number of occasions. Together with a student of mine (Joachim Pehl), we just convinced ourselves that the JPL library of SWI-Prolog is really cool. Basically JPL allows you to call Prolog from Java and Java from Prolog. But the question is, of course, how easy is it and can you easily go back and forth . For instance, can we call Prolog from Java and call back Java from Prolog and share Java state throughout? Sure it works! PROLOG PORTION FOLLOWS % This library is all we need to call Java from Prolog :- ensure_loaded(library(jpl)). main :- % Create an object jpl_new(class([],['Test']), [], X), % Printing objects is like printing object ids write(X),nl, % Access a field of the object; happens to be static jpl_get(X, state, Y), % Prints whatever the state's value is write(Y),nl. JAVA PORTION FOLLOWS // This jar is all we need to call Prolog from Java import jpl.*; public class Test { public static int state = 0;
Read more

Lecture series on advanced (functional) programming concepts

[ Added 10 Aug 2010: Here is the link to the first lecture's video: " The Expression Problem ". ] If you are a programming nerd or something of a similar species, you may know of C9 Lectures at http://channel9.msdn.com/tags/C9+Lectures . Several of the lectures are given by Erik Meijer who has turned many chapters of Graham Hutton 's book " Programming in Haskell " into videos. In my recent, recorded lecture on " Programming Paradigms and Formal Semantics ", I also incorporated Graham's text, but you should really watch Erik's lectures, if you haven't---they are more fun. I am inspired by his ability to present relatively simple content in such a crisp, insightful, and enjoyable manner. In the aforementioned lecture, I covered all kinds of "crazy stuff" though, and in the end, I had to deliver body bags to my Bachelor students---in the form of a radically simple examination. Thanks a lot btw to @grammarware for helping with t
Read more

Should I declare defeat on the research topic of API migration?

Of course, I won't, but perhaps I should! Then, I could turn to lower-hanging fruits in research, which I first need to spot, which I can't though because I am a bit obsessed with API migration (and admittedly some other stuff such as megamodeling ). Sigh! It was around 2004 that I became interested in API migration and I have talked about it here and there ever since. Perhaps I am thinking that talking about a difficult problem of interest helps in discovering the solution of the problem, or at least a sensible path to go. Wishful thinking so far! In theory , the objective of API migration made a lot of sense while I was on the XML team at Microsoft because there are obviously way too many XML APIs. In practice , nothing happened on this front because I didn't understand automated API migration well enough back then. Add to this that API migration is something that is potentially risky for the API provider and the API migrator . So you need to mash up a rocket scientist
Read more