[antlr-interest] Re: 2.7.2a4 ANTLR/C# - build ok, panic shutdown

slightlynew gackle at shaw.ca
Thu Dec 5 18:04:58 PST 2002


Micheal,

> Care to talk a little about these unit tests and the tools/harness
> you employ for them. About your ANTLR-related testing in general in
> fact.

Sure.  I'm using NUnit 2.0.  I write unit tests to exercise whatever 
production code I write.  The unit tests are in a separate project, 
which I find to be easiest for a number of reasons; for example, 
the production code doesn't have to ship with a dependency on the 
test framework.

The unit tests' job is, of course, to catch errors and verify that 
the code is behaving correctly.  But over time they grow into a 
comprehensive test suite that (usually) fails immediately when some 
aspect of the program is broken.  Knowing right away whether 
something's been messed up is remarkably freeing to the developer.  A 
good analogy is that of a safety net underneath a tightrope walker.  
You can go faster and try riskier things without fear.  In 
particular, upgrading something from one version to the next becomes 
relatively low-risk and painless.

In terms of ANTLR, the unit tests call my lexer and parser with 
various expressions, statements, and so on, verifying that the well-
formed stuff is parsed as expected, while the invalid stuff generates 
the expected errors. I try to imagine weird things that might go 
wrong and then write tests that will fail in those cases.  It's not 
complicated.

Many people think that systematic unit testing means taking a 
productivity hit in exchange for greater quality, because of the time 
it takes to write the tests.  But actually, in my experience, it 
*saves* time.  That's because there's far less manually stepping 
through code, troubleshooting weird integration issues, etc.
And, the time you're saving is largely in the drudgery aspects of 
programming.  That means you spend a higher percentage of your time 
coding, which is the fun part of programming.  So it turns out that 
systematic unit testing gives greater productivity, better quality, 
and more fun, all at the same time.  I'm not sure I could claim that 
for any other programming practice I've tried.

The picture is different with an already-existing large system with 
no unit tests.  In that case, it may not make sense to go back and 
write, say, a unit test for every public method.  But you can still 
use xUnit to write higher-level functional tests that give you good 
coverage, and many of the above benefits.

- Daniel

--- In antlr-interest at y..., "micheal_jor" <open.zone at v...> wrote:
> Daniel,
> 
> > Overriding panic() is certainly a workaround, and indeed was the 
> > first thing I did after discovering the problem.  However, I 
don't 
> > really see that as the point.  The important thing is whether a 
> > library should handle fatal errors by shutting down the calling 
> > application without warning!
> 
> Not ideally but it works [ ;-) ], it's due for revision real soon 
> anyways.
> 
> > A further problem with overriding panic() is that while you can 
do 
> > this for lexers, you cannot do it for parsers or tree parsers, 
> where 
> > it is a static method.
> > 
> > By the way, Micheal, just for curiosity I also built the C# 
codegen 
> > with Antlr 2.7.2a6.  I was able to do so quite easily, and my 
unit 
> > tests all passed without modification (unlike the upgrade from 
> > 2.7.2a2 to 2.7.2a4).
> 
> I did mention that it should be possible. There are a few problems 
> with doing that (some of which you've already encountered but you 
can 
> certainly do useful work with it).
> 
> Care to talk a little about these unit tests and the tools/harness 
> you employ for them. About your ANTLR-related testing in general in 
> fact.
> 
> > In fact, the discrepancies between the C# and 
> > the main Antlr branch are now quite few, which bodes well for 
> merging 
> > the two streams.
> 
> I'm not sure I follow you here. What discrepancies are you 
referring 
> to?
> 
> > What I wasn't able to get working in Antlr 2.7.2a6 was that third 
> > parameter that Terence added to the AST constructor syntax: #
> > [FOO, "Foo", "FooNode"] (or something like that!)  I couldn't get 
> > that to work either with Java or C# (having ported Terence's 
> changes 
> > to the C# action.g).  Antlr rejects the third parameter with a 
> syntax 
> > error saying "unexpected ','".  Is there something else one needs 
> to 
> > do, to get Antlr to use the new action.g?
> 
> Quite a bit more. ANTLR/C# 2.7.2a6 would debut as soon as it's all 
> done.
> 
> Cheers,
> 
> Micheal


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



More information about the antlr-interest mailing list