Re: [Codenarc-developer] Inline violations idea

[Hamlet D. <ham...@ca...>]

The biggest issue is that the getLineNumber() method in Groovy is often returning the wrong line number. As long as the line number hacks in CodeNarc's AstUtils are well tested, then it seems like a reasonable change. However, I would not have two different public methods on the API. I don't think many projects depend on these test utilities, and it would be a lot cleaner to just have one way to make assertions rather than two. So I would go ahead and break backwards compatibility if we really do believe that this is a better API for testing. 

-- 
Hamlet D'Arcy 
ham...@ca... 

----- Original Message -----

> I'm a bit late to the party but I really like the idea. I never wrote
> too many rules but when I did line counting and passing those maps
> to assertViolations() was the biggest pain point in the otherwise
> terrific testing support for writing rules in Codenarc. So it would
> be nice if you pushed on and made all those changes required by
> Chris so that he has no choice but to merge it in. :)

> On 07/05/13 11:44, Chris Mair wrote:

> > Thanks Artur. That is a clever and innovative approach for
> > validation
> > of rule violations. Pretty cool! I acknowledge that configuring the
> > violation line numbers and source line text and keeping them in
> > sync
> > after edits can be cumbersome. Your solution is a concise way to
> > avoid that.
> 

> > Some things to consider about the existing approach:
> 
> > · The existing approach and associated validations are there
> > intentionally to validate the exact line number in the generated
> > Violation; line numbers are not always completely straightforward
> > and automatically correct (especially around imports and
> > annotations). Though the CodeNarc framework and helper classes
> > generally make that a non-issue now, I would not want to skip line
> > number validation for all rules/tests.
> 
> > · The source line text is not guaranteed to be the full source line
> > text; it may be a subset, or it may be null/empty. So, you could
> > not
> > generalize that it is always the full source line.
> 
> > · I do like the way the existing approach allows a clean,
> > standalone
> > example of source code that causes violation. It can also be easily
> > copied to the help documentation or pasted in an email (admittedly
> > a
> > minor benefit).
> 

> > That all being said, I do think your approach has value. I would
> > want
> > to implement this as a separate method name, perhaps
> > assertInlineViolations (), rather than adding complexity (and
> > potentially parsing the source code?) for all invocations of
> > assertViolations (). If you are willing to expand and harden your
> > POC as you mentioned, I think we can pull it in.
> 

> > Thanks.
> 
> > Chris
> 

> > ------------------------------------------------------------------------------
> 
> > Learn Graph Databases - Download FREE O'Reilly Book
> 
> > "Graph Databases" is the definitive new guide to graph databases
> > and
> 
> > their applications. This 200-page book is written by three
> > acclaimed
> 
> > leaders in the field. The early access version is available now.
> 
> > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> 

> > _______________________________________________
> 
> > Codenarc-developer mailing list
> > Cod...@li...
> > https://lists.sourceforge.net/lists/listinfo/codenarc-developer
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Codenarc-developer mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-developer