Turned a year!
Just remembered that the PowerShell testing suite turned a year. As it believed, approx. on November 28th, 2011, the result of a programming mistake, of course (a piece of code didn’t work in PowerShell, just a usage mistake), the decision to write up C#-cmdlets has been made. 🙂
Since then, our frameworks have changed significantly. It was only UIAutomation which was the root of the suite. Now, there are several frameworks published and several versions upcoming.
Shortly, I’d drop a word about the Software Testing Using PowerShell team plans. From the features that are almost ready to those that are only in mind. What will the upcoming winter bring to us?
UIAutomation:
- on fail, the Invoke-UIA[ControlType]Click cmdlets will try Win32 click by default. This behavior (the user wants it click and it clicks) is most awaiting (thanks to JohnQuest for the idea).
- the Set-UIA[ControlType]Text cmdlets will check the result and try to use SendKeys on a failure
- the Set-UIAControlKeys cmdlet will try several times to put text into the input field, checking the result
- UIAutomationSpy are going to produce more useful code. Moreover, the code produced is going to be faster. How? When possible, UIAutomationSpy will set the -Win32 parameter, what, in certain situations, accelerates tests significantly (working with controls near grids and listviews is slow; this can be healed by using Win32 handles).
- UIAutomationSpy will finally check code that it generates (sometimes what can be got by hovering over is not the same that can be got by searching in the Automation tree).
- at least ten pages of documentation as what is published is like a mad mix
- setup for the module
- Java Access Brigde (that has not been tried yet)
- we will try to use UIA2 if it’s possible to combine two UI Automation technologies
SePSX:
- support for ChromeOptions, InternetExplorerOptions and FirefoxProfile
- fast-working ‘named’ cmdlets Get-Se[TagName]
- cmdlets for working with tables
- SeleniumSpy
- in a perspective, support for other browsers
TMX:
- TestLink add-in (missing functionality)
- TFS add-in
- working with test cases in SQLite, TestLink, various files
AWSPSX:
- EC2 and S3 cmdlets to allow automated test lab deployment and execution
ESXiMgmt:
- a small set of cmdlets allowing us to start/stop/suspend/snapshot guests
Internals:
- these days we are working on harnessing a Dependency Injection framework. By now, SePSX is partially sitting on Autofac 2.6 and we are also experimenting with NInject 3 in other projects. TLAddin has benefited from using Moq. The reasons we are working on not a business-understood features are such:
- the number of tests is growing and the testing cycle should be running every several minutes. Hundreds of tests we already have are for daily framework verification (they take twenty minutes or more, what is critical for us). On the opposite, a hundred of unit tests we have already had take less than five seconds (and around seventeen seconds does Gallio take to get the consciousness at the start of testing)
- we need more through-out testing of our code
ESXi Management module
Many would interest for what reason one more VMware management module has been written. In the last years the VMware team did the great work and now thousands of administrators can do almost everything, having learnt the cmdlets intuitively or by reading one of the great books on the topic.
Well, it’s the truth. Seemingly, absolutely all can be done using the standard PowerCLI cmdlets set. However, what would you do in worse circumstances? Those who work in small companies, or in mid-size companies that are not truly generous to its IT infrastructure, don’t have most of what the PowerCLI cmdlets offer. Why? The cmdlets evolve following the evolution of the flagship products. Many operations are now considered as infrastructure-level, thus they are gone on a host level. As a result of the evolution, owners of hardware running ESXi 4+ can’t automate the overwhelming majority of the lab-upbringing duties.
And here appears the ESXiMgmt module. What is it? This is a combination of a PowerShell module, the plink.exe utility and the underlying original PowerCLI cmdlets.
How does it work? As you may know, most of or even all the available operations with the host itself and the hosted virtual machines are being done via Linux utilities. Something like that there are the vimcmd utilities set somewhere in the ESXi file system, and a number of APIs for a number of programming languages and frameworks that simply leverage these utilities.
As a matter of fact, the ESXiMgmt module does the same. Cmdlets have names similar to those given to parental PowerCLI cmdlets. By calling them with parameters, you call the Invoke-ESXiCommand cmdlet. This forms parameters for plink.exe from the parameters the cmdlet given and runs plink.exe with parameters. Plink.exe in turn runs the given parameters that call the ESXi vimcmd utilities.
Disclaimer: the ESXiMgmt module contains exactly what I needed in the time I projected, built and run the lab (and built a new lab again with other parameters, and incremented the existing lab). There wasn’t the goal to copycat all the PowerCLI cmdlets offer.
At a time of its first public release (i.e., now) the ESXiMgmt module consists of the following advanced functions:
1) connection and disconnection
Connect-ESXi, Disconnect-ESXi
2) creation a folder in the file system and copying files to the file system from a local drive
New-ESXiFSDirectory, for the second goal the original Copy-DataStoreItem is used.
3) registration of a new virtual machine
Register-ESXiVM
4) start, stop and suspend of a virtual machine
Start-ESXiVM,Stop-ESXiVM, Suspend-ESXiVM
5) getting machine Id by its name and getting machine name by its hostname
Get-ESXiVMId, Get-ESXiVMName
6) execution of a custom command
Invoke-ESXiCommand
7) generation of dozens of virtual machines using one as a template
New-ESXiVMs
All of them will be described in greater detail in the upcoming posts. The 1.0.0.1 version of the ESXiMgmt module available here (already includes plink.exe) and posted here.
To start using the module all that you need to do is 1) download it 2) unpack in the module directory or in a directory of your choice 2.1) in the latter case type the path to unpacked module folder in the smaples 3) run samples. To generate new machines you need to wait a couple of days until I publish more information.
Software testing automation based mostly on PowerShell 