[antlr-interest] gUnit for v4?

Terence Parr parrt at cs.usfca.edu
Fri Apr 20 17:45:22 PDT 2012


On Apr 19, 2012, at 5:06 PM, Kieran Simpson wrote:

> On 20/04/12 3:11 AM, Terence Parr wrote:
>> Hi Kieran,
>> 
>> thanks very much for the feedback. What exactly were you testing when you say parts of your grammar and in different combinations? Were you testing the ASTs you created? It was very useful for that. Since v4 automatically builds trees, those trees will be correct unless there's a bug so there's nothing really to test as far as I can tell.
>> Ter
> 
> Ter and list,
>  I must admit I haven't been watching the development of v4 that closely so perhaps there's something I'm not understanding about AST construction/rewrite rules.
> 
> An example from my current project is that you can define an entity inside a namespace.  However there is the ability to define the namespace as part of the entity def (it can make the input more readable).
> 
> eg: namespace(namespaceId)  { entity(entityId) ... }
> 
> eg: entity(namespaceId:entityId) ....
> 
> Conceptually the result is the same, a namespace tree with the entity as a subtree.  Using gUnit I've been able to write tests quickly! that test whether input combinations not only match, but build the correct AST structure.

Since ANTLR would be constructing trees, you are only testing validity of sentences.  Seems like we can make a simple function

assertEquals("rulename", "entity(namespaceId:entityId) …", "tree for that entity");

> Coupled with Token testing, and more complicated parser rules I've found gUnit valuable to my TDD process as I can come up with a bunch of input and refactor my grammar as I go.  Given my target AST walker language is C, in my C++ tests (the rest of my app is in C++) I can focus on semantic issues.  The separation of concerns testing wise is also nicer as I can isolate syntactic issues from semantic problems.

Hmm…yeah, i still think a function/macro could work here.

Ter


More information about the antlr-interest mailing list