My favorites | Sign in
Project Home Downloads Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 170: Annotations with colons don't work with cfscript attribute syntax
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  bob.silv...@gmail.com
Closed:  Mar 2010
CF9


 
Project Member Reported by bob.silv...@gmail.com, Jan 19, 2010
What steps will reproduce the problem?

A test function like this:

function thisShouldThrow() mxunit:expectedException="myExceptionType" {
	whatever;
}

generates a syntax error because of the colon in the attribute name.

This works:

/**
* @mxunit:expectedException "myExceptionType" 
*/
function thisShouldThrow() {
	whatever;
}

But I don't like it ;-).  I think we should support both syntaxes.

This affects both mxunit:expectedException and mxunit:dataProvider

To keep backwards compatibility we need to continue to support the colon notation, but should 
also add others.

Should we just add support for expectedException and dataProvider (i.e., lose the namespace)?

Jan 19, 2010
Project Member #1 marc.es...@gmail.com
I've been thinking about this: what about a function named
"getAttributeValue(AnnotationName,DefaultValue)" or whatever. and it looks for
"mxunit:#AnnotationName#", then "#annotationName#".

so if I use:

@expectedException="whatever", it'd find that


Jan 19, 2010
Project Member #2 virtix
i initially put in the mxunit:Annotation as a kind of a namespace deal to avoid
conflicts with other frameworks or tools. but i'm totally ok with dropping the
'mxunit:' and go with @expectedException @dataprovider , etc.. 

the question i would have, is do we deprecate the mxunit: prefix? or do we support
both syntaxes?
Labels: CF9
Jan 19, 2010
Project Member #3 bob.silv...@gmail.com
Doesn't deprecate mean that the old syntax is still supported, but discouraged, and will eventually be dropped?  
Is that what you're suggesting, or are you suggesting we actually drop it right now and developers will have to 
deal with it by fixing any code that breaks?
Jan 19, 2010
Project Member #4 virtix
deprecated means that the syntax old syntax will still work, but will be dropped in
future versions, and migrating to the new syntax is encouraged.
Jan 19, 2010
Project Member #5 bob.silv...@gmail.com
OK. I was just asking because it seems like deprecating often does not result in a syntax being dropped - it 
usually hangs around indefinitely. So I was wondering if you really wanted to deprecate it, or if we should 
actually try to drop it.

Jan 19, 2010
Project Member #6 a.hask...@gmail.com
I think deprecating the proper way of doing things is stupid. Namespace is the proper
way of doing it. Why should the proper way be changed do to the fact that an engine
does not properly support the syntax? 
http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=81673

Jan 19, 2010
Project Member #7 marc.es...@gmail.com
Yeah, but when we change MXUnit's name to BMFUnit, then we'll have to change the
attribute names, too. If we don't use the namespace, then that's less to change.
Jan 19, 2010
Project Member #8 a.hask...@gmail.com
Dude what you just said is the perfect place where deprecation makes sense, at that
point you deprecate mxunit namespace and BMFUnit is the expected namespace. 
Jan 19, 2010
Project Member #9 a.hask...@gmail.com
getAttributeValue(AnnotationName,DefaultValue) is the perfect way of doing this by
the way. 
Jan 19, 2010
Project Member #10 marc.es...@gmail.com
But then I have to go change all my code that uses mxunit:whatever to
bmfunit:whatever or mightyunit:whatever.

whereas if I have no namespace, I don't have anything to change.

and wouldn't MightyUnit be a sweet name for a framework?
Jan 19, 2010
Project Member #11 bob.silv...@gmail.com
I know this probably goes against the principles of why the namespace was introduced, but really, we're 
talking about annotations on a unit test, right?  And annotations with very specific, meaningful names. What 
are the chances that another framework, in addition to MXUnit, is going to need to be added to a given unit 
test, and that it is going to have annotations that conflict with those of MXUnit?

Rather than a developer needing to add annotations from another framework with the same name, it seems 
more likely that a developer may switch to another framework entirely.  If that were to happen, and that other 
framework used the same annotation names, chances are, as they're named appropriately, they'd fulfill the 
same purpose.  In that case getting rid of the namespace would actually make the unit tests portable, so it 
seems advantageous.


Jan 19, 2010
Project Member #12 marc.es...@gmail.com
I was thinking the same thing, Bob: that our annotations are very specific anyways.
it's not like "hint".
Jan 19, 2010
Project Member #13 a.hask...@gmail.com
I can think of 2 frameworks that broke on OpenBD b/c it implemented assert and the
framework does as well as a private method in a CFC. Who knows what can be added and
you shouldn't care, b/c you use a namespace. You don't see the namespace in
annotation in Java b/c annotations are just classes so you remove ambiguity through
package structure. If that did not exist in Java they would use namespaces, if you
doubt this look and see how Schema for webservices work in Java, I'll give you a
hint, the namespace translate to the package structure. The point is this is a
safeguard and requires nothing to implement it. Why should we dictate to users and
force them down a less future proof path, give them the option and let them weigh the
risk. 

What if expectedException works differently in bmfunit or XYZ other unit testing
framework? Then my code needs changed, or worse I might get false positives.
Namespaces exist to mitigate this risk. Lets say we want to change how dataproviders
work in version BMFUnit well you can either create a new attribute name that is not
as good, make everyone update their code, or suck it up and deal with the shit ass
implementation you forced yourself into. Namespaces enter into play, not so much, the
old namespace is deprecated and the new one is where the new functionality can be
picked up.  
Jan 19, 2010
Project Member #14 virtix
yeah, the "annotations" we're discussing would only be used in the context of an
mxunit testcase, so, the namespace is implied (mxunti.framework.TestCase). whereas i
initially used the 'mxunit:' namespace in component methods for the purposes of test
generation. in that context, a namespace would be warranted. with that said, i like
the simplicity of expectedException="" ... dataprovider="q".

marc's getAttributeValue(...) solution sounds fine.

Mar 10, 2010
Project Member #15 bob.silv...@gmail.com
I fixed this awhile ago in the MIT branch. Sorry I neglected to update this ticket.

I added a getAnnotation() method into TestCase.cfc which is now being used for both expectedException and 
dataProvider.
Status: Fixed

Powered by Google Project Hosting