My toolkit

Everytime I (re)install my development computer I need to think about all the tools I need and use on a regular basis. For that reason, and maybe to inspire others, here’s my list of essentials tools and software for a (Delphi) developer.

Delphi

  • Delphi itself ofcourse. Usually the most recent version, although I always keep the previous version installed as well for bugfixing and patches that might need to be done.
  • GExperts – an open source plugin with many enhancements for Delphi / C++ builder
  • DDevExtension – another open source plugin that greatly enhances the Find/Use unit dialog
  • IDEFixPack – Andreas also makes a great IDE plugin that fixes several IDE bugs in-memory
  • TestInsight – a plugin that lets you run DUnit_ unit tests in your framework. Depending on settings, you can even let it run every time you save or compile your project.
  • FastMM4 – (Almost) every project will benefit from this alternative memory manager, and it’ll help you track down those nasty memory leaks.
  • MadExcept – Stack traces, exception handling, reporting.

Tools

  • Beyond Compare – The best compare and merge tool out there. Especially their 3-way merge of conflicts is better than any I have seen before.
  • Notepad++ – With the right plugins, a very versatile text editor.
  • 7-Zip – Isn’t this the defacto unzipping tool for Windows by now?
  • KeePass 2 – Keeping track of all those hard-to-remember passwords
  • VirtualBox – For running all those different environments you need for testing
  • Paint.NET – More functional than paint, less bulky than other image editors
  • Greenshot – Screenshot tool that can do screen, window or regions and offers image editing immediately integrated
  • SumatraPDF – Who needs Adobe Reader when all you need is view and read PDF files.
  • GrepWin – Text and Regex search for files and contents, for when you know what you need, but not where you left it
  • Bulk Rename Utility – The UI takes some getting used to, but the functionality to rename a bunch of files is sometimes required. And this is the most versatile tool I found so far
  • Expresso – Free regex utility that lets you write, test and validate regular expressions
  • Pencil – Quickly create wireframe UI mock-ups that don’t distract with implementation details
  • TortoiseGIT / TortoiseSVN – Depending on the source control system I’m working with, because despite doing lots of stuff on the command line, I’m still predisposed to using a UI when possible.
  • XVi32 – simple and to-the-point Hex editor.
  • Resource Hacker – to see what’s inside those DLL’s and binaries
  • WireShark – Inspect your netowrk traffic
  • SysInternals suite – I don’t use all of them, but I usually download the entire set to be sure
  • SoapUI – If you ever programmed against a SOAP interface, you’ll have this installed
  • REST Debugger – Free tool for debugging REST interfaces

Note: You can get a lot of these tools in 1 stand-alone installer from Ninite. Silent download and install of the software you select, without any extra’s.

If you have any additions, remarks or alternatives, please let me know!

Integrating Ranorex with TeamCity using PsExec

The problem

As part of our ever increasing effort to automate more of the builds and tests that we run on our applications and thereby detecting defects as early as possible, integrating our UI testing solution Ranorex with our TeamCity CI server became more and more important.

When using TeamCity to build your application and testsuites, you run into an interesting problem; TeamCity by default runs under the Windows System account and, by extension, does not have access to an interactive desktop. Ranorex, because of it’s very nature, needs a desktop to interact with.

Several solutions float around the internet, but they all boil down to allowing your TeamCity service on the agent running the test to run as a local user, a user that is also logged in to the machine and has a visible desktop.

And it is this final sentence that provided me with the most headaches. Our buildagents in TeamCity are all virtualized and our systems people do not allow RDP access to the agents.

Enter PsExec

PsExec is a small command line utility provided by Microsoft as part of their Sysinternals suite. It allows you (provided you have the right credentials, the executable is available on the target machine, etc.) to run any executable on a remote machine, and have it interact with the desktop. As Ranorex can build a command-line testrunner application, and use it’s floating license available on the network, we can add a normal machine to our buildprocess with a vanilla Windows install on it.

This command line runner can generate a .rxlog file with the results of the testrun and will exit with an exitcode indicating success (0), failed test (-1) or other errors (any positive number). Sadly, this exitcode is not propagated by PsExec, so we had to find a different solution for letting the testproject fail when the tests fail.

Our new setup

Anonymised, our new setup looks kind of like this:

  • The BuildApp project in TeamCity delivers an installable artifact to the BuildAndRunTests project
  • The BuildAndRunTests builds the ranorex test from the sources.
  • A batch file that does the following is started on the agent:
    • Copy the installer to the testrunner machine
    • Copy also the testsuite
    • And copy a batch file to the testrunner
    • Start the copied batch file on the testrunner using PsExec
    • Await the run of the test and copy all results back to the buildagent for further parsing
    • Parse the log from the command line and make the build in TeamCity fail or succeed
    • Copy the .rxlog and .rxlog.data files to the Reports subfolder folder in the Artifacts folder of the project and rename them to *.html and *.html.data

The batch file on the testrunner has it’s own responsibilities

  • Use the installer to install the version of our application we want to test
  • Redirect standard output to a log file
  • Start the Ranorex test runner
  • Read the exit code of Ranorex and output this to the logfile as well

This means that we can parse the log from the testrunner machine using e.g. powershell and set the exit code based on the original exit code of the Ranorex testscript. When our UI tests fail, we see the result within minutes of a commit. Moreover, since TeamCity is capable of integrating custom html files as build-reports, we can view the results of our testsuite immediately in our CI server.

2016-07-15 16_29_26-Windows Editor __ Testing __ 399 TestAutomationRanorex _ #23 (12 Jul 16 17_22) _