
zfisherdrums
-
Posts
382 -
Joined
-
Last visited
Reputation Activity
-
zfisherdrums got a reaction from phuocvo88 in Unit Testing in AutoIt...sorta
While working on an automation framework for my company, I found myself missing some of the xUnit testing capabilities that more "traditional" development environments employ. Then I remembered hearing Martin Fowler at a conference speak of the somewhat trivial task of implementing unit testing frameworks for companies he had worked for.
So what follows is my attempt at providing some unit testing functions in AutoIt. It is by no means as robust as the xUnit frameworks nor is it a highly-optimized, textbook implementation - but it suited my needs at the time.
Edit:
TestSetup and TestTearDown functionality added. These functions are accessed using "Call()" and are not required per se. But AU3Check will kickback non-fatal errors if they are not defined in the Test Script. See the examples uploaded for further clarification.
The example "CalcCore.zip" contains a minature automation framework for testing some functionality in "Calculator". The included "FunctionLibTests" and "ActionLibTests" describe the tests associated with their respective libraries. Run these to see Testing.au3 in action.
Here is Testing.au3:
Testing.au3
After placing Testing.au3 in the include directory, download this example:
CalcCore.zip
Current Limitations:
> Output File does not contain the periods and "F"'s that appear in the console.
> Only 3 Assertions
> Others only you know about
-
zfisherdrums got a reaction from argumentum in LazyReader(c)
Useless Humanity, Inc.
2000 Awesome Hair Drive
Nashville, TN 37211
Re: Problems with the use of LazyReader©
Dear BERT;
Thank you for your interest in LazyReader©. We're sure you'll agree that our product will help you realize huge gains in the areas of personal productivity and knowledge advancement. I know it is hard for me to believe that we're practically GIVING this away for $19.95 free!
In regards to your inquiry, our R&D department has provided the following response:
"Looks ok, but do you really need to clear the clipboard at the start??"
Yes. Otherwise LazyReader© will read whatever is currently in the clipboard when it starts up. Our testers discovered problems when large amounts of text resided in the clipboard upon startup. LazyReader© would begin rambling and because this version has not introduced our proprietary multi-threaded speech synthesis, the process must be killed via the Task Manager. This also is a problem in normal use if you copy a large area of text by accident. We hope to have that updated version released in tandem with our .NET port. Keep a look out for updates!
"and I also get an error"
You WOULD get an error! Er...sorry. We're kind of sensitive in the R&D department. Late nights, early mornings, coffee might as well be in an IV. You get the picture.
LazyReader© has been programmed to patently refuse to read certain text it deems kinda boring. Perhaps you could highlight something more fascinating like a Wiki on moon rocks, Oprah's Book club, or the UFC web page. We've never had any problems with LazyReader© reading about BJ Penn.
Another possible workaround would be to download the Microsoft Speech API from their web-site. We'd send you the link , but we cannot remember it. And our IT guy is a horrible speller, so our corporate firewall prevents access to any site with '.com' in it. Sorry.
You might also try to remove that offending line. It isn't necessary for the use of LazyReader©. It just gives you that Stephen Hawkings crooning that the kids are going for these days.
We hope this answers your concerns with the use of LazyReader©. Please feel free to contact me should you have any other questions or concerns.
Sincerely,
Bob MacNimara
Customer Support/Company Friend Maker/Crowd Pleaser
Useless Humanity, Inc.
-
zfisherdrums got a reaction from errandfox in Towards approximating a 'yield' statement
Not the most useful thing as it is not feature complete, but a fun experiment nonetheless.
Edit: What does it do? Well, it attempts to approximate the yield statement found in other languages, i.e. Ruby and C#. The purpose of the yield statement is to give control to a specified function from within the called function's body. Some security limitations - as well as my own intelligence limitations - make this example more of a conceptual example than fully functional. But oh well.
Why did I place it here? Perhaps some poor soul will find themselves trapped under mounds of maintenance code, much of which relies on repetitious looping and iterating. Perhaps it will spark a better implementation. Who knows. That's the beauty of these forum thingys.
#include <WinAPI.au3> Func Iterator( $loop, $yield ) Local $errorFlag = 0 For $i in $loop if ( IsObj( $i ) ) Then $command = StringFormat( "%s ( $item )", $yield ) ConsoleWrite( $command & @CRLF ) Call( $yield, $i ) If @error <> 0 then $errorFlag = @error Else $command = StringFormat( $yield, $i ) ConsoleWrite( $command & @CRLF ) Execute( $command ) If @error <> 0 then $errorFlag = @error EndIf Next SetError( $errorFlag ) EndFunc #region Example Functions ; The following are example functions that will be called by the Iterator function Func ShowMeFromArray( $msg ) ; Helo Werldz MsgBox(0, "ShowMeFromArray", $msg ) EndFunc Func TwoToThePowerOf( $exponent ) ; Display two to the power of a supplied exponent MsgBox(0, "TwoToThePowerOf", 2 ^ $exponent ) EndFunc Func ShowMeFromCollection( $item ) ; Some kind of window-releated activity is simulated here ; Because of AutoIts restrictions against window-operations ; proceeding from Call'ed, Execute'd statements - we'll use ; the WinAPI include to achieve the desired result. MsgBox(0, "ShowMeFromCollection", "Press 'OK' to maximize " & $item.LocationName ) _WinAPI_ShowWindow( $item.HWND, @SW_MAXIMIZE ) MsgBox(0, "ShowMeFromCollection", "Press 'OK' to minimize " & $item.LocationName ) _WinAPI_ShowWindow( $item.HWND, @SW_MINIMIZE ) SetError( 1 ) EndFunc #EndRegion Dim $test = StringSplit( "1,2,3", "," ) Iterator( $test, 'ShowMeFromArray( "%s" )' ) Iterator( $test, 'TwoToThePowerOf( "%s" )' ) ConsoleWrite( @error & @CRLF) $oShell = ObjCreate("shell.application") $oShellWindows=$oShell.windows Iterator( $oShellWindows, "ShowMeFromCollection" ) ConsoleWrite( @error & @CRLF) -
zfisherdrums got a reaction from justdoit123 in Any framework for the automation testing
Sounds awesome!
-
zfisherdrums got a reaction from mLipok in Mini File Watcher Utility
Attached is an application that monitors a specified directory for changes made to files with a specified extension. I'm placing it here in its current state because I have taken so much from the AutoIt community; I need to start giving back.
Included in Zip File
3 Koda Forms
Config.ini
File icon
AU3 script file
Instructions-Lite
The user selects the directory to monitor, a directory to ultimately hold any selected file(s), then uses "Options" to set the file extension to monitor (default is "*.rtf").
When a modified file is detected, it is immediately copied to the user's temp directory with a temp name. Files can then be manually prefixed, copied to the specified directory, or cleared altogether from the ListView. Double clicking the item will bring it up (currently uses the explorer shell). When copying, the app can overwrite any files sharing the same name or rename it with a suffix number to create unique files.
I've used this utility to not only compare differences between files on the fly, but also as a kind of Version Control with scripts I wrote. Any time the file was saved to the monitored directory, the app would create another copy. Soon, I had multiple versions of the same script with the ability to retrieve any one at a click(...well, more like two).
Upon closing the app, all temp files are deleted.
Limitations:
> Sorry, no sub-directories at this time.
> Only 1 file extension is monitored per session (multiple instances could be run as a workaround).
> Virtual-Desktops appear to fire off multiple writes to the desktop. Monitoring the desktop under these conditions can results in a slew of partial temp files.
> More I haven't had time to think of.
Only read the below if you want to know WHY this was made.
The Original Problem:
Software I was testing for my company had experienced a Date format issue between US and Canada. The problem had to do with how MFC interpreted the dates and this led to valuation problems as well incorrect dates in print. Myself and another individual were charged with testing the changes stemming from this bug, paticularly the print changes.
I knew that upon creating a print document, a print component created an RTF document suitable for baselines and regressions. I also knew that AutoIt would come in very handy with automating the tests cases used to produce the print. But I grew tired of always writing code in my scripts to handle retrieving/copying the output files especially when my test cases were changing daily.
The Partial Solution:
The app is called "Mini" because the algorithm used to monitor the directory is probably crude compared to ones used in .NET, Win32, etc. Also, it only monitors 1 specified directory for 1 specified file extension.
I had thrown together an app in .NET to monitor a specified directory for modified files. I abandoned this initial approach for 4 reasons. (1) Company anti-virus software caused multiple triggers of the FileSystemMonitor component (I've since learned a workaround, but oh well). (2) My colleague was using a locked down system, so my .NET 2.0 app would require a Framework she could not obtain without a move of Congress. (3) I'm too lazy to code my GUI's so that SharpDevelop/MSBee could target a .NET 1.1 installation. (4) Coding in AutoIt is more fun for me.
Mini_File_Watcher.zip
-
zfisherdrums got a reaction from allenljwan in Identify .NET controls by their Name
Have you had any of the following problems when trying to identify controls in a .NET app:
- the control ClassNameNN changes often
- cannot obtain any information that uniquely identifies the control
Often times, we are stuck trying to identify them using less than robust means. Fortunately, there is the WM_GETCONTROLNAME message. Using this, one can identify a .NET control by the name given by the developer at design time ( or given at run-time ).
Attached is a port to AutoIT from a C++ example posted here.
NET_DumpAllControlNames will dump all control names for a given .NET Windows Form.
NET_ControlGetHandleByName will provide a handle for a given control name on a Windows Form
Example:
#include <DotNetIdentification.au3> ; "Test App" is a fictitous application that contains a control named "txtShowMe". $WindowName = "Test App" $WindowText = "" $control = NET_ControlGetHandleByName( $WindowName, $WindowText, "txtShowMe" ) if @error = 0 then WinActivate( $WindowName, $WindowText ) ControlFocus( $WindowName, $WindowText, $control ) endif
NOTE:
- Not all .NET controls have unique names assigned to them.
- Also, this will NOT provide access to cells in a .NET Data Grid. For those, take a look at MS Active Accessibility implemented in oleacc.dll and its AutoIT implementation here.
- If you wish to discover the names of specific controls using a utility similar to the AutoItInfo tool, check out Managed Spy or Ranorex Spy.
TODO:
- Break out Setup and Cleanup into distinct functions
- Fill out error handling
- Once registering OnAutoITExit functions is implemented, cleanup on errors
DotNetIdentification.au3