MXUnit's handling of syntax errors

[Brian FitzGerald]

I have MXUnit running now and it rocks! Thank you Marc for all your hard work on this project.

I am curious about MXUnit's handling of syntax errors. In my current testSuite.cfm I am pulling in a running a bunch of methods from a single Test cfc. It works great if the tests explicitly pass or fail, and also works well with certain types of errors.

What I am wondering, and granted this may not be feasible, but what is the expected behavior in the event of a syntax error? Is there any way for MXUnit to handle this, or is it up to the parent application's error handling system at this point?

Here is an example of what I'm talking about (below).

<cffunction name="getUserShouldReturnUserBean">
       
    <cfset var myName = "Marvin" <!--- oops, I didn't close my cfset statement! --->
       
    <cfset assertEquals(
        myName,
        "Marvin",
        "the user bean did not return the expected ID. something weird is going on."
    )>

</cffunction>

In my newbie brain to unit testing, I was hoping this would show up as an "error" test in the report, but it seems like it maybe can't handle hard errors that way. Thanks for any insight.

Best,

Brian

[Nathan Strutz]

Brian,
Maybe we're the only people out on the lists today :)

As you said, that's a syntax error. In CF, you can equate that to a compile error, the rough meaning is that the server can't even get up to the point of testing it. Your unit test can at least point out that the file won't compile, but unfortunately that's not a kind of error that you can catch.

Again, I don't know how helpful this is, but I hope you can understand it a bit better

Nathan Strutz

--
You received this message because you are subscribed to the Google Groups "mxunit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mxunit+un...@googlegroups.com.
To post to this group, send email to mxu...@googlegroups.com.
Visit this group at http://groups.google.com/group/mxunit.
For more options, visit https://groups.google.com/d/optout.

[Brian FitzGerald]

Maybe we're the only people out on the lists today :)

I think so! I'm lucky you're around or I'd definitely be waiting for my own echo to bounce back.

Your unit test can at least point out that the file won't compile

By "point out" I think you mean that you'll just notice the hard error when you run your build/tests, correct? As you've just mentioned, there really won't be any way to point this out in any graceful way if I'm understanding correctly.

Your comment was quite helpful, just trying to make sure I got it solid.

[Nathan Strutz]

Brian,
That's exactly right. You (and thus MXUnit) can't try/catch a compiler error. It could probably be done with a site-wide error handler (Application.cfc's onError() should be able to pick it out), but I'm not 100% sure about that, and either way it would break the MXUnit context. Anyone, correct me if I'm wrong, though. Please.

If you really want to catch those errors, obviously you can run the test yourself to see if it's broken, but before that you can just hit your application and watch it break before having to even run the unit tests. If you want to catch it before, use ColdFusion Builder, it alerts you to syntax errors and does a pretty good job, often before you even hit save. 

Beyond that, it's mostly a matter of getting extremely comfortable with CFML, making your code consistent and readable, always use some previously agreed upon amount of proper indenting and capitalization, and that sort of good developer practice.

If you're worried about other people running your unit tests and getting syntax errors (I'm not really sure what's up, but I'm just stabbing at the wind here), that's the exact reason why most of us use a local development server (and source control software like Git!) before we push anything up to a team dev/test/staging/etc server - so we can mistype things and break stuff without affecting how our teammates and customers perceive us.

Nathan Strutz

[Brian FitzGerald]

Again, thanks Nathan!

Everything you said makes a lot of sense and is familiar to me. For one reason or another Unit Testing has been one of the "final frontiers" for me as a CF dev and something I somehow never got around to putting in place.

The syntax thing came up just because I got everything setup and I was manually putting in all sorts of crazy errors to get stuff to break (to see how MXUnit would respond) and noticed that it didn't like the "hard errors," which, thanks to your description and refresher, is now quite clear as to why.

I recently got into improving our gulp build (mainly for front-end assets, jslint, sass, minification, revisioning, etc.) and figured no better time than now to get this thing to call some automated server tests as well. It's working great!

Basically from the gulp build it's just hitting a fw/1 url http://myapp.com/?action=system.runtests using nodes request module

That url returns a json object that tells me whether it passes or fails. If it passes, I continue with the rest of the build, if it fails, I kick open a new browser window to render the tests result page. Not that you asked, but I think it's pretty cool so figured I would share.

Anyhow, thanks again Nathan; your insight is very much appreciated. I hope you enjoy the rest of your weekend!

Brian

[Bill Rawlinson]

I'll try to remember to share a test tomorrow that does a full compile of your site and report am mxunit error for each file that doesn't compile.