I have a handler (main.cfc) that uses WireBox to inject a model (authenticator) as a property for use in one of my events (main.onRequestStart). I have mocked my authenticator in my integration test but I’m not sure how to inject it into my event handler.
If I was testing a model, I’d be able to just setPROPERTY() with my mock and everything would work fine. Since handlers have to be executed, I’m not sure how to get the execute method to use my mocked authenticator instead.
Any insights would be appreciated. Thanks!
My understanding is that you don’t mock things for integration testing. The purpose there is to actually spin up the full framework and execute a request from start to finish as opposed to a unit tests which isolates a single method and mocks all parameters and dependencies.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Brad:
Yeah, that makes sense. I suppose if I want to test my handler in isolation, I’d just treat it like any other model, right?
I’ve updated my tests based on this new understanding.
Thanks!
Yep, and since you never put any business logic in your handlers and simply route the view and service calls that won’t ever be necessary, right? 
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
As a ColdBox newb, I know that’s the rule of thumb, but how does one handle writing the onRequestStart event? I’ve sequestered one handler for handling these application lifecycle events. Surely these will have some amount of logic in them, won’t they? Or where is the recommended place for that logic?
I can provide examples if this is too theoretical.
I was being a little tongue-in-cheek. There will always be logic here and there where it makes sense. To be honest, I don’t tend to use the lifecycle event handlers in favor of interceptors. There’s no real difference other than the fact that one is an event handler and the other is just a model (that inherits from another base class). Well, I take that back, interceptors are more robust-- they can be async, they can chain together and share a stringbuffer, they can also be announced ad-hoc by your application.
I don’t know when the lifecycle handlers were introduced into ColdBox, but to be honest I would just as soon not have them in favor of interceptors. It basically just boils down to more than one way to accomplish things.
http://coldbox.ortusbooks.com/content/interceptors/application_life_cycle.html
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Do you have any open source apps that you’ve written where you show your preferred way of handling said lifecycle events with interceptors instead? The ColdBox Samples prefer the lifecycle events or are too basic to really have a lifecycle event. I’d much prefer to follow the techniques of ColdBox experts (such as yourself).
I’ve used interceptors a ton, but unfortunately most of the complex apps are closed-source client work. A great place to see just about anything you could want (including interceptor use out the wazoo) is the Contentbox source code. ContentBox really capitalizes on custom interception points which is what makes it so freaking extensible without ever having to touch the core.
Most of the sample apps are really old and that’s possibly why they favor the event handler lifecycles but I’m just guessing. There’s not really cut and dried best practices for this stuff, just use what works best for you.
The easiest way to do interceptors for sure is simply to add the interception methods to your /config/Coldbox.cfc file. It’s a little-known behavior that the main ColdBox config (as well as all module configs) get registered via the interceptorService as interceptors themselves.
So in your ColdBox config just add a method called “preProcess()” and dump/abort the arguments scope. Reinit and you’ll see it fired at the start of the request and has data available to it. A good example of an interceptor is preRender(). That one gets all the rendered HTML from the view and layout and you can modify it prior to it going out to the browser. Super cool.
The “regular” way to do an interceptor is just to put it in any model CFC. Most people do /interceptors/myInterceptor.cfc. Since the full path is required to register the CFC, ColdBox doesn’t really care where it lives. The reason interceptor CFCs must be declared in the config is because it’s an array and the order matters since you probably want security firing first etc… So just put your preProcess(), preREnder(), etc method in a basic CFC and add it to the interceptors portion of the config.
interceptors = [
{ class=“interceptors.foo” }
];
My only caution with interceptors is to be careful to document what you put in there since they may be harder for a noob to track down when they first see your code base. For instance, it’s common to have a preProcess() interceptor that sticks useful stuff in the prc, but to a new dev, they might not be able to easily figure out how the heck it’s getting put there.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com