0.8.0 Preview 1: UIARunner, UIAutomationSpy, and modules are published


Even though with some bugs and ugly-looking (it never was our intent to write GUI tools besides modules:)), UIARunner is published. As far as I know, this is the first GUI wrapper for PowerShell that looks like a software testing tool. 🙂

This preliminary version supports:

  • running one script at a time
  • using the UIARunner.ps1 file (in the application’s folder) as a configuration file
  • generating test report on the fly (in the GUI)
  • generating test report on the fly as a CSV file (both GUI and command-line versions produce such output)
  • unattended runs
  • the GUI version also shows how many test results are passed, failed and the velocity in newly introduced measures called ‘test results per second’ (trps)
  • of course, it supports basic sorting in the grid.

Known issues are numerous (again, this project lacks of professional GUI programmers :)):

  • bad multithreading
  • poor informing about what happened at the PowerShell level
  • and many, many lesser bugs.

Anyway, this version is worth experimenting with. Each package includes several simple scripts to try the runner. Scripts work similarly to other PowerShell hosts, note, however, that you need to use try/catch blocks to avoid terminating errors.

One response

  1. Over the years I have had considerable enexripece with this old hack – not time to learn new tricks. This has been much of the issue behind the success of Windows in IT. The GUI has made management of the IT infrastructure much easier. The cost has been that today’s Administrators have become spoiled because they believe there is no learning with a GUI tool. Not true! The GUI is no different than CLI tools but does force tool designers to approach the layout of a tool in a much different way. By forcing all things through this much narrower and more defined interface we have been able to reuse past lessons in tool navigation.With CLI tools we have no visual interface to display navigation and usage clues so some knowledge it required. In the past this baseline knowledge was normal and attainable by most Admins. Look at Unix. How many shells does the average Unix system support. It used to be normal for Admins to learn all the Unix shells as products would be delivered with support scripts in any of the normal shells. Today Admins rely on the GUI the same as they relied on the older Unix shells. Newer “shells” in Windows seem like a return to the past and do not fit nicely into the modern Admin’s world. This is to be expected and, I suspect, is the normal evolution of the environment.PowerShell is new now and, as such, it will be looked at skeptically by IT Managers and Admins for some time. Mostly PowerShell will be used by vendors and developers to simplify deployment of application management tools. We already have seen one of the first of these in “PowerGUI” which provides a GUI platform for the deployment of PowerShell scripts. Maybe the modern Admin will never need to learn Windows Internals or PowerShell in the future. Most newer Admins that I have worked with have less knowledge about the technical aspects of computing and more knowledge about company policy and user satisfaction. This has been the drive of IT management since they are rated and funded based on these major TQM metrics. The IT effort has been shifted and elevated. The computer and the software along with remote vendor support has taken the technology out of Information Technology. It would be better to call it Information Technology Support. Further advances in computer automation will undoubtedly remove all need for technical expertise at the corporate level as the network is moved farther into the cloud.

Leave a comment