[Testbox v1.0.0] "Variable ISEXPECTEDEXCEPTION is undefined" on erroring test

71 views
Skip to first unread message

Adam Cameron

unread,
Dec 20, 2013, 2:57:58 PM12/20/13
to col...@googlegroups.com
G'day:
I'm only using TestBox to replace MXUnit at the moment, rather than using it in anger.

I'm writing some tests for some code I am about to write, so they all currently error (calling a function that doesn't exist). This is cool, it's what I want.

However when I run the tests, I get this error from within TestBox:

Variable ISEXPECTEDEXCEPTION is undefined.

coldfusion.runtime.UndefinedVariableException: Variable ISEXPECTEDEXCEPTION is undefined. at coldfusion.runtime.CfJspPage._get(CfJspPage.java:316) at coldfusion.runtime.CfJspPage._get(CfJspPage.java:296) at coldfusion.runtime.CfJspPage._get(CfJspPage.java:284) at cfBaseSpec2ecfc697396152$funcRUNTESTMETHOD.runFunction(C:\apps\adobe\ColdFusion\10\cfusion\wwwroot\frameworks\testbox\1.0.0\testbox\system\testing\BaseSpec.cfc:469) at 
[etc]

testbox\system\testing\BaseSpec.cfc; line 469

The code in question is this:
try{
evaluate( "this.#arguments.spec.name#()" );
}
catch( Any e ){
if( !isExpectedException( e, arguments.spec.name, arguments.runner ) ){ rethrow; }
}

(BTW: evaluate()? Seriously? Anyway...)

And, as Brad pointed out to me on Twitter, isExpectedException() is defined and alive and well at line 672:

private boolean function isExpectedException( required exception, required specName, required runner ){

So this should be no problem.

I don't think is this anything to do with my code, but for the sake of completeness, 'ere 'tis (also on Github @ https://github.com/daccfml/scratch/tree/master/blogExamples/unittests/testbox)

// Application.cfc
component {

this.mappings = {
"/testbox" = expandPath("/frameworks/testbox/1.0.0/testbox"),
"/mxunit" = expandPath("/frameworks/testbox/1.0.0/testbox/system/testing/compat")
};

}

<!--- runTests.cfm --->
<cfoutput>
#new testbox.system.testing.TestBox(
bundles="Tests"
).run(
reporter="simple"
)#
</cfoutput>

// Tests.cfc
component {

public void function beforeTests(){
variables.beforeTestsRun = true;
}

public void function setup(){
variables.setupRun = true;
}

public void function testInitFunctions(){
assert(structKeyExists(variables, "beforeTestsRun"));
assert(structKeyExists(variables, "setupRun"));
}

public void function testThatErrors(){
throw(type="TestException", message="This is a test exception", detail="Note that it is NOT being caught / tested for. This is by design");
}

}


This is a repro case, not the actual test I was having problems with, but the behaviour is the same.

It could be an install problem (although it really just seems like weirdness!), and the details of my install are here: http://cfmlblog.adamcameron.me/2013/12/unit-testing-tdd-switching-off-mxunit.html

That's a long article, but the basics are that it's not installed in the default recommended /testbox dir in my webroot, but in a separate dir, with a CF mapping to point to /testbox. I have also followed the instructions for remapping /mxunit.

Tests that should pass do pass. I've just noticed that tests that fail (as opposed to erroring) also give the error above. And tests that error behave as described here.

This is running on ColdFusion 10,0,12,286680, enterprise licence.

I'm having some trouble getting Railo to see Testbox, but will check that out and see what it says... and post back. Must dash...

Any ideas?

-- 
Adam

Luis Majano

unread,
Dec 20, 2013, 6:22:28 PM12/20/13
to col...@googlegroups.com
Ok, I was able to reproduce.

Seems it is a bug at the moment since the method does not exist as the component is NOT using inheritance!  That’s why.  So my method injections are failing for that private method.


FYI: I use evaluate due to there is no native invoker in ACF.  In Railo I could easily do this notation:


But in ACF that chokes.  So have to compromise to make it cross-engine compatible.
--
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
For Bug Reports, visit https://ortussolutions.atlassian.net/browse/COLDBOX
---
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+u...@googlegroups.com.
To post to this group, send email to col...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

signature0.jpg

Luis Majano

unread,
Dec 20, 2013, 6:27:07 PM12/20/13
to col...@googlegroups.com
Ohh, so forgot this.  In order to run under MXUnit compat mode, you MUST inherit from the MXUnit TestCase or the BaseSpec class.
signature0.jpg
signature0.jpg

Adam Cameron

unread,
Dec 21, 2013, 5:46:49 AM12/21/13
to col...@googlegroups.com

FYI: I use evaluate due to there is no native invoker in ACF.  In Railo I could easily do this notation:


But in ACF that chokes.  So have to compromise to make it cross-engine compatible.


https://gist.github.com/anonymous/8067756 (oh for CFMLFiddle, but this'll have to do)


That said, apparently the MXUnit compat in TestBox works fine on CF9, which is a good thing. And invoke() is CF10-only. So perhaps best left as-is.

Just for the sake of interest, I examine how to get around using evaluate() in almost all situations on my blog. This bit deals with the scenario you have here: http://cfmlblog.adamcameron.me/2013/08/evalulate-is-really-slow-is-it-now.html#objectMethods

That said: [shrug]. Just some info for you.

-- 
Adam

Adam Cameron

unread,
Dec 21, 2013, 5:52:12 AM12/21/13
to col...@googlegroups.com
Ohh, so forgot this.  In order to run under MXUnit compat mode, you MUST inherit from the MXUnit TestCase or the BaseSpec class.


Blimey, I didn't notice that! In my original test file I had been messing around with TestBox-specific stuff, and had removed the extends="mxunit.framework.TestCase". WHen I then switched over to trying MXUnit compat, I didn't re-instate it! My repro case (above) was derived from that CFC, so perpetuated the error.

Groan.

Having reinstated the inheritance, everything is fine!  Cool!

Its a pity your test case CFCs don't need to be of a certain type, as that would have clarified that error from the outset. It would also help mitigate a failing MXUnit always had in my opinion: that it determines whether a CFC is a test CFC by its NAME rather than its TYPE (eg: it's a subclass of TestCase). This name-based approach isn't great OO, especially if the capability to do it "properly" is right there.

But, anyway, I digress.

Cheers for being a second pair of eyes for me, Luis!

-- 
Adam

Adam Cameron

unread,
Dec 21, 2013, 9:24:19 AM12/21/13
to col...@googlegroups.com


Ohh, so forgot this.  In order to run under MXUnit compat mode, you MUST inherit from the MXUnit TestCase or the BaseSpec class.

I've actually found that even when using a normal TestBox runner, I need to extend testbox.system.testing.BaseSpec, otherwise I get the same problem.

I'm now running my test CFC via this code:

<!--- runTests.cfm --->
<cfoutput>
#new testbox.system.testing.TestBox(
bundles="TestMakeStopwatch"
).run(
reporter="simple"
)#
</cfoutput>

And unless I extend TestMakeStopwatch.cfc with BaseSpec, I get this same error if my tests fail or error?

I've raised a coupla other bugs, but I'm sure you'll get emailed about those separately.

-- 
Adam

Luis Majano

unread,
Dec 21, 2013, 11:58:24 AM12/21/13
to col...@googlegroups.com
Yes, the issue exists with NON-inherited specs.  I fixed this now on the repo.  Thanks Adam.
--
signature0.jpg
Reply all
Reply to author
Forward
0 new messages