Re: [Codenarc-developer] Inline violations idea
Brought to you by:
chrismair
Menu
▾
▴
Re: [Codenarc-developer] Inline violations idea
|
From: Chris M. <chr...@ea...> - 2013-05-11 01:29:48
|
I’m glad we are getting some discussion and feedback on this. I don’t think there is any question about breaking backwards-compatibility. Artur’s changes integrate with and are compatible with the existing APIs. We would continue to support new and old validation styles. I don’t think anyone is suggesting migrating all of the existing code to the new style (and potentially breaking other rule developers’ code), but correct me if I’m wrong. I am still leaning toward a separate method for reasons including: · This is a different style of validation; I think making that obvious is beneficial. · I am worried about the potential for confusing the new and old styles of validations. For instance, a developer intends to use the new style , but neglects to annotate the source code with validations, and the test succeeds, even if it “should” not. · There may be design/complexity advantages to keeping the new and old styles decoupled. That may give us more flexibility to extend or redesign later. · It would just be adding a single protected method to the AbstractRuleTestCase API. Chris From: Hamlet DArcy [mailto:ham...@ca...] Sent: Friday, May 10, 2013 3:22 AM To: Marcin Erdmann Cc: cod...@li... Subject: Re: [Codenarc-developer] Inline violations idea 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... _____ 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 _______________________________________________ Codenarc-developer mailing list Cod...@li... https://lists.sourceforge.net/lists/listinfo/codenarc-developer |