Adam Ness said the following on 06/04/2009 03:36 PM: > On Thu, Jun 4, 2009 at 1:12 PM, Peter J. Farrell <[email protected] > <mailto:[email protected]>> wrote: > > > Mach-II 1.8 allows you to programmatically reload a single listener / > filter / plugin / property.cfc without incurring additional > overhead of > reloading the entire framework. The dashboard application provides a > nice GUI for it or you can use our API. > > > That's really nice, and I can't wait to use it once it's out of Alpha, > but it still results in pretty much the same debugging workflow: Go to > the Dashboard, reload the listener, go back to the application, reload > the page, Dig for hints. Faster cycle time, but still not optimal. The 1.0 version of the Dashboard that includes the reload functionality is in stable. As for the stability of 1.8, nothing is stopping you from using it for development purposes.
Plus, you can make use of the logging output from the MachIILogger which provides great trace out. > I suppose a CFEclipse or Bolt plugin to fire off a "reload this > listener" event could be written, and potentially run on an auto-build > of a cfc that extends MachII.framework.listener. In fact, that would > be really cool, but CFEclipse is closed source with no documented > extension API, and Bolt's extension API isn't publicly available yet. We're thinking of adding an additional attribute for the dynamic reload mode (0) that includes looking at the changed listeners. Right now we keep a hash (timestamp + byte size of the CFC) to see if things have changed. Another option is to have the dashboard poll the server to check and reload changed components at a specified interval (like every 3-5 seconds). > > As you already outline, this is very complex. What about > listeners that > do announceEvent or call redirectEvent. Are you mocking your session > facade that this listener example depends on? Your example just shows > getting at data, what about listener methods that do flow control > (call > a service layer method then make a decision on what announce event to > make -- gets more confusing when event-mappings are there). I think > your example is actually a simple one. Solving this problem is more > about what needs to get mocked when testing listeners. What about > testing filters which usually do flow control? Mix in ColdSpring here > makes things harder because you might need to mock up your services > calls as well. I guess there are a lot of unanswered questions > how this > can be efficiently. > > > Exactly, and I'm trying to start to figure out some of those answers. > Short of creating a whole new Mach-II.xml and services.xml, with a > bunch of Mock objects, i'm kind of at a loss. I was hoping for > suggestsions from a few folks who might have tried this before, and > what successes they had, and what snags they ran into. Well, that's mostly what would have to be done to accomplish this. Middle-tier layers like this are hard to test easily and nobody has really come up with an elegant solution. > > Have you looked at Selenium from OpenQA? It's really designed for > testing components of an application that are hard to unit test > (such as > in this situation). Not that I'm thumbing down your unit testing of > controller level components, it's really a difficult problem to solve. > Plus, you mention the problem of the view layer (which Selenium really > does a wonderful job on). > > > Selenium is a good functionality testing tool, but I was hoping to > find a good method for narrowing in on the Controller layer errors, > which Se lenium only partially addresses. Well, actually we use it pretty heavily here and it's a great at first pass testing to see if things appears to work right. Another option is to build a test harness application (which we've done for Mach-II -- it's hard to unit test the request handler or event context out of the context of a real request) which you do write listener calls, output data to a view and use Selenium's assertions to ensure things are working right. > > Really what we are talking about here is what kind of mocking > framework > needs to be built so you can "construct" a partial dummy request > to unit > test controller level Mach-II components. > > > Heh, maybe a wish list feature for Mach-II 2.0? :) Maybe you would like to help? You could help with engineering a solution. Team Mach-II would be happy to collaborate with you if you want to contribute to the project. Contact me if you are interested. Best, .Peter --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
