> On Fri, Mar 17, 2017 at 6:22 PM, Justin Carr via 4D_Tech wrote: > OK, so it's Friday afternoon and I've got a few moments while I sup on a cold > bevvy.
Hey J, thanks for chiming in! > David & I kind of got the fervour about CALL FORM/WORKER at the same > time and this is one of the things about them that really captured our > imagination. I have Justin to thank for getting me to jump to V16. And the idea he outlines in his post is *very* cool. As Justin points out, it's actually simpler in the code than it is to explain! If you grasp this idea, you'll have a pretty high level mastery of how the CALL FORM and CALL WORKER commands work. > We are using CALL FORM and CALL WORKER to automate unit testing of our forms. > This has been something we've been wanting to do for a very long time but has > been impossible or at the very least impractical prior to the introduction of > these two commands. A side note for those following along at home. Eggplant is the name that comes up at this point amongst people that know about automated testing. And Justin and his group have looked at Eggplant. For those of you that don't know already, Eggplant is a long-established GUI testing suite that works in a novel way. Rather than tap into the APIs for UI widgets on a specific platform, it compares screenshots. That's a pretty crude summary as Eggplant is vastly more sophisticated than that - but the basic technology is to compare screen components (text, images, etc.) with current screen contents. It's scriptable, flexible and pretty impressive. It's virtue is that it works like a sort of automated user - one that can spot when something has changed (an icon is different, the expected text did not appear, a weird window showed up, a button click does nothing, etc.) It's virtue is also it's weakness. Namely, that it doesn't get under the skin. Sometimes what you want to test is not the UI itself, it's the behaviors that the UI drives. Say you've got a drop-down, an entry area, a button, and a display variable. You want to test what happens when you select different items from the dropdown - say a discount rate or a post code, whatever - and different values in the entry area. The button click runs a calculation and the result appears in the display area. Perhaps you could do that with Eggplant, but there are times when it's more involved and you can't. So, with Justin's approach, you get to pass in instructions for setting values (the popup and the entry area), clicking things (the button)...and you are inside of 4D code. Meaning, you can test the outcome. The outcome might be how a variable is set, what selection of records is found, etc. Now, if all of your code were structured as perfect little headless APIs that you could write headless test code for then, well, then you probably wouldn't be on this list. Who has massive code bases going back to the 1980s and 1990s? I'm seeing a lot of people raising their hands;-) Between Justin's solution and Eggplant, there's not a lot of GUI-driven testing that you can't do. I know that formal testing is (understandably) not of great interest to many one-person development organizations, but it is a very big deal to larger organizations, particularly ones that face regulatory scrutiny of any kind. Note: Someone from Pelican Engineering did an automated testing some years back at a 4D Summit that included discussion of Eggplant. It was a very well-received event. Sorry, I don't remember the year or other details. > There is very little cost to setting it up if you implement your form and > object methods as separate project methods, and if you use meaningful names > for the objects on the form. Both really good points. To take advantage of CALL FORM, you're much better off having form methods and objects that call a global method or methods. I started 1+ thread(s) on this subject in the past couple of months for this very reason. Meaningful object names are a good call for this sort of system. Instead of passing pointers, you pass object names and derive pointers on the recipient side. > The beauty of this system is that the forms and their associated methods are > driven completely externally, so they need to have absolutely no extra logic > built in to handle the messaging. Furthermore, the control methods for driving > it are completely generic. The only thing that needs any knowledge of the form > interactions is the method that's describing the unit tests. It's a real thing of beauty to behold. There's no special test mode that you have to add to your code. Your code stays the same! You just now have the scriptable tool to provoke the items on the form. So nice. It's a bit hard to grasp exactly how easy and cool this is until you see it. But it really is easy and cool. Well, "easy" once Justin figures it all out in about an hour ;-) > We have a small number of message types that can be sent to the form.... > It sounds complicated, trying to write it all out, but the framework is > actually beautifully simple. It just consists of a handful generic methods, > none of which extends to more than about 40 lines of code If you're implementing this at home, you'll know you've got it right if you also need only a handful of small methods to do what Justin describes. > It sounds complicated, trying to write it all out, but the framework is > actually beautifully simple. It just consists of a handful generic methods, > none of which extends to more than about 40 lines of code: > > - UT_UIMessageSet<XXX>Value > - UT_UIMessageDelay > - UT_UIMessageTriggerEvent > - UT_UIMessageQueue > - UT_UIWorker > - UT_UIBroker > > And strictly speaking the delay capability is probably not necessary, but it's > kinda cool watching the form objects update as if by magic in front of your > eyes. ;-) If your form were expecting some other even to happen from some other process, then they delay might be super helpful. For those of you that haven't made the connection, Justin is the same person that gave us the 4D DebugLogReader tool: https://github.com/j-genie ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
