[testbox-2.3.0] Odd Issues During BDD Test Creation

[lucee-4.5.2.018]

Hi Folks,

I’ve been using BDD syntax for roughly a week. It’s great, but it has a very aggravating problem. I don’t have a good test case for it, because it’s intermittent, but maybe if I give my horribly vague description, it will ring some bells for those who know the implementation.

While writing tests, I sometimes run into an obscure error (next time I’ll grab it when I see it, sorry) from the TestBox core code that tells me something is missing from array position 1 (or similar). I’ll make a bunch of changes to try to fix it, which generally speaking, won’t fix that error. On a hunch, I decided one time not to modify the test code, but to restart Lucee. Magically, the test started working. Now, when I get that problem (which is pretty common while I’m writing tests), I restart Lucee, then I’m back in business. Obviously, that’s an onerous workflow.

Here’s another bit of info that I’ll supply, on a hunch that this issue might be related to my environment: Lucee runs on a Vagrant-handled (Ubuntu 12.04) VM, and the app CFML source (FYI, as well as the Lucee WEB-INF, which is auto-generated under the web root) is being shared (from Windows) via NFS. Although I haven’t really had any problems with that configuration, I do notice that certain things in the OS don’t work quite the way they would if files were native, such as tail -f reverting to polling, since it can’t detect changes on that remote filesystem.

Any theories?

I can add this as an issue on GitHub if you’d like, but I didn’t want to do so right off the bat, because the steps to reproduce are nonexistent, and I don’t have the error handy, ATM.

Thanks,
Jamie

Might it be that you need to add a pagePoolClear() to clear cached cfc code?

We usually add this to the onrequest start portion of the tests, so we know we clear the template cache

Jamie Jackson, what version of Lucee are you on? That sounds similar to an issue I ran into a while back where the array error was actually coming from Java, not CFML. It was a compilation bug and I had to restart to fix it. The culprit was the instrumentation in the java agent. Since I was on Java 8, I just removed the java agent and never saw it again. It was something that would trigger when editing a file that’s called with two different cases on a case-sensitive operating system.

Does the screen shot look like this?

I’ve been wrestling with it all evening actually. What I’ve found is that this happens when there is a “catastropic” error and nothing is returned to the test engine. If you comment out the test that is causing the problem, everything works fine. It isnt’ that the test failed per se, it’s that nothing was returned for the test to evaluate. The difficulty is that, since the code that is running is actually the testbox code, there is no way from the error dump to know what test was being run when it happens so it’s theoretically to have an entire directory full of tests and not have any idea which one was causing the issue until you start commenting out tests until you find the right one.

Any thoughts?

Dan, are you getting that error on the newest version of TestBox? 2.4?