unfortunatelly I have a GUI desktop application running on Windows and compiled using Borland C++ compiler. I know it's a very old technology, but that's the life. The company I work for have lots of free licences for QTP. But to be honest I don't like this tool and I want to change it with some open source alternative.
I have an experiance with automation Web services using Selenium, and some java swing applets.
I created my tests based on Java/JUnit. I'm wondering if I can create some tests in Java to test my C++ application - that would be great. If that's not possible if I can use any C/C++ libraries to create my own test framework.
That shouldn't be unit tests. I want to create rather a suite of functional tests.
I want to be able to localize objects like buttons, tables, cells, etc., perform action like clicking, changing focus, etc.
In addition I have access to source. But this is rather an old spaghetti code and I don't have much experiance with C++ apps.
What do you suggest?
We use Sikuli and have been quite happy with it. It works outside of the various automation APIs so it handles non-standard UIs very well.
Open Source Tools
White is a .NET based UI automation tool that can automate win32 applications among others types. As long as the controls used in your app expose their content/behaviour using Windows' standard UIAutomation hooks then you should be able to use it to do what you need.
UIAutomation Verify is another CodePlex project that works with the same APIs to automate UIA compliant UIs.
Visual Studio
Finally if you have access to it then Visual Studio 2010 has scripted UI test functionality built in Premium/Ultimate editions - Coded UI Tests. This supports .NET, native and web applications with record/replay and scripting functionality.
Robert, if your company already has licenses of QTP, I suggest you use that. It's the right tool for the job, and there's no sense reinventing the wheel if your company already owns it. It has its warts - my main objections are to the limited IDE and VBScript scripting language - but it did not become the market-leading tool by accident. There are not a lot of open-source options for testing a Windows C++ GUI app. The main commercial options you should consider are HP QTP, IBM Rational Functional Tester and VS2010 Coded UI Tests.
I agree with Robert that QTP is sometimes not the best tool, especially when you want it to wait for the desktop application to finish its processing. QTP commands are not synchronous, meaning that QTP does not wait until the previous command finishes execution before moving to the next call. We had a lot of issues with this. We are now planning to write a c# dll that can do this for QTP and include that in our QTP programs to make QTP to dynamically wait until the Desktop application finishes its processing. Currently, to my knowledge, no such wait functionality is supported by QTP.
Also, coming back to the object recognition issue, We did have a lot of issue with this and took the alternative route of invoking commands using Mnemonics through keystrokes in QTP. As Simon has already mentioned, this could be due to non-exposure of the GUI elements. We did not have much control in this regard and so we did not investigate further on this.
In many big stores/rental/service companys the system they are using for managing customers and looking up products is based on a Text User Interface (TUI). Are there any reason why they choose TUI over GUI or is it just old systems?
From my experience, it's just old systems. If the old system still works, many companies don't see why they should spend a lot of money only to get the TUI replaced by a GUI.
Now is 2017 and TUI is still widely used in stores, gas-stations, etc...
I personally find TUI (specially TurboVision based apps) much more eye-appealing then too rich GUI apps. Also, by looking into how users use TUI apps (mostly spend time with numerical keyboards without need for mouse) I get the feeling they are faster in using TUI.
For those who are using vim/emacs/terminals,etc (ie, not an IDE proper) what sort of projects are you working on? Are they big? Production? Are these the tools you use at work? Or mostly for smaller things...or big things broken into small things? Sorry...enough questions.
I ask because I'm studying computer science right now, and am super excited about it. I had an internship programming J2ME for a government agency recently and it was Netbeans and eclipse all the way. So I've only had a few "minor-league" years in the business.
In short, what is practical for the CL type tools, versus an IDE such as 'beans and VS. I've got a lot to learn, and the CL tools will probably teach me, versus shielding me like an full on IDE might.
What sort of projects are you working on?
All kind... vim is my main "IDE" anywhere
Are they big?
Yes... My FOSS project CppCMS written almost 100% in vim
Production?
Yes, most of production code (Not FOSS) I write today I use vim.
Are these the tools you use at work?
Yes.
I would explain severak simple things:
vim provides almost all tools IDE does, highlighting, spellcheck, autocomplition, working with multiple buffers, build, context "jumps" (decl, def) and much more
It is extreamly portable, I work with it on Windows, Linux, OpenVMS, Solaris, FreeBSD.
It is very light in comparison to bloated IDE.
There is only one thing I do use IDE today: debugging hard bugs.
Emacs/Vim can be used for any sized projects.
Generally, you won't get to choose the environment, the job you find will have one already picked out for you (unless it's non-Java programming in Unix, in which case use what you want).
I wouldn't sweat the choice, just learn to use which ever editor/IDE is available to its utmost extent.
I use (and have used) Emacs for personal projects, and in two different companies on software projects exceeding 10M lines of production code each.
I use emacs. I would recommend emacs. I have used emacs since before it was emacs: TECO, TV, and the e macro package on the Decsystem-20.
I can use vim if I need to but what you learn is largely what is at hand and you get into.
Yes, learn one or both. And I would say, if the IDE fits, wear it too.
I use vim for everything, I hate IDEs, they're too bloated for me.
I haven't used it for any massive projects (because I haven't written any massive projects), but if I were going to, I would still use vim.
When learning I new language, I believe it's best to not use IDEs at all, and to learn the "proper" way of doing it (like for c++, learning the command line switches and using makefiles).
Twenty years ago all my programming was done in plain text editors, mostly emacs, but technology has improved over the years.
I still do use plain text editors to write code occasionally, but only when it is inconvenient to install an IDE on the machine where I'm writing code. For example, a few times I've stopped by a client site without my laptop and wanted to write a quick program.
This is also an issue with certain embedded systems, where you may want to update the code interactively through a RS232 or USB based command line interface.
Most modern IDEs provide enough acceleration to the code editing process that I will install one whenever I expect to use the computer for development for more than two or three hours.
I use vim for everything from small one-off scripts to 1000+ line production code. It is so versatile that working in any other environment seems constricting. If I'm part of a project that necessitates a standard environment (IDE) then I'll do as much coding as I can in vim and then import into the ide.
I believe everyone should be able to operate effectively in a command-line environment. You can't always be sure that anything except the basic tools will be available on the target machines, you can't be sure that you'll have enough system to pull up a full IDE, and you might actually find the system you're building is too complicated for an IDE.
I've built systems that have consisted of multiple interoperating clients and servers distributed across multiple physical machines. In these efforts, I have used command line tools almost exclusively in the server side. I will use DDD when I can, but I also know the underlying gdb. If the clients are Windows, I'll use the Visual Studio IDE, but if they're UNIX, I'll go with the command line.
Figure out how to work effectively using minimal tools. You'll be a better developer and you'll actually appreciate the integrated tools more, if they're done better.
BTW, I put Emacs in the IDE class. I've got a friend who comes in and fires it up first thing and doesn't leave the environment all day. It's more than an IDE, in fact, since he does mail, surfing, etc. in the thing, or so he tells me.
For large projects with 100+ files, using an IDE is very important. But there are lots of small small things which you need to keep doing all the time while working on even large projects. Firing up the IDE for all of these may not be worthwhile. Having a good command on a powerful editor like Vim or Emacs is something I would consider as an essential skill for any programmer. But an appropriate IDE should also be used to accelerate regular development work as per project needs.
Hmm... Well, look at it this way:
I open code in emacs. I edit it. I use code completion (and I've even played with intellisense emacs)... When I'm ready to compile, I hit CTRL+F7... A key I've bound... It builds in a small popup window... If there are any errors, I can jump to them in the code by hitting f8 (another bound key)... Once it's all building, I hit f5... (this runs a little program I wrote that parses the Makefile and determines the path the executable)... This starts the debugger in a small popup window... I can click on code lines to set break points... etc... I debug... I can "next" through the code with F10... I can "step" through the code with F11 (more key bindings)... When it's all done I hit Shift-F7 to package (.rpm) the project.
So, do I have an IDE? Or am I just using a plain text editor?
1. Yes. 2. Any kind of project.
There is no limit to the size of a system that can be developed in Vim/Emacs/Unix, in fact, there are fewer limits than there are in IDE's. Let's look at a few things I use...
SYSTEM LINES OF CODE
Linux kernel 10,000,000
NetBSD 4,000,000
Ruby 200,000
Those are pretty big systems.
I don't believe any of them were developed with IDE software.
I tend to agree that for learning it is a good idea to understand the basics: the fact that you edit the code, you compile it with a compiler, link it with a linker, debug it with a debugger.
It makes it easier to grasp the concepts. And it makes easier to move from platform to platform.
So, learn vi, make, gdb, some version control system (git, svn).
But for production I would say that getting familiar with the "standard IDE" of the environment is a must (Visual Studio for Windows, XCode for Mac OS, Eclipse for Java, etc.)
No mater what other say, mastering an IDE will increase your productivity.
If you used vi/emacs for 10 years and try Eclipse or Visual Studio for few days, you will say that they are bloated and don't offer anything in exchange. That's BS. The more open minded you are, the better you will be.
I use Emacs to develop commercial software with size of several millions LoC, and massive use of templates, etc. I use CEDET + gnu global as auxiliary packages + yasnippet, etc.
well...I have to say that I'm a vimmer. Using a IDE, I don't to care so many things like when you use editor like vim/emacs. But when you do a bit more, you will find the IDE you use is more hindering than helping in your program developping process. alas...if you insist in using vim/emacs as your editor, you will encounter "a deep learning curve", you will waste so many time even to acchieve so trivial a function in your editor,you will be desperate when you are busy catching up with your timetable if you just pick them up......you have to settle down and start leaning and also playing with editors and a couple of days, you will find you've already achieve more than you can ever expect!
My standard IDE is a flock of xterms running some mix of vim editors, man page documentation, debuggers, log tails, and command lines to execute things, plus an instance of Firefox for pulling up additional docs or (where applicable) testing web-based code. This is what I use for all projects these days, regardless of size, whether personal or professional.
Pretty much the only time I've seen real benefit to using an IDE has been when I've been working on platform-native GUI apps, where they make it so much easier to build forms and wire up their controls. But I haven't done that sort of work in over a decade - the last one I did was in Deplhi, back when Borland still owned it; I think version 4 had just come out, although it might have been 3.
Emacs is a great tool (so is Vim) for programming, and I use them to develop my code for physics research. As added benefit (for me) Emacs handles remote files nicely via Tramp, so that's big boom for me since I very often have to visit remote servers.
With that said, every time I need to write an application with a GUI and within a large framework (like c# with .NET or the android framework) I always find it hard to development with just emacs. The IDEs (Visual Studio, Eclipse) simply have everything including autocomplete and lookup with appropriate content from the framework, and debugging, even though code writing part is always unsatisfactory (I always end up installing some sort of emacs plugin for the IDE, which always fall short of Emacs proper!).
Sometimes it just takes too long to setup an environment in Emacs for those kinds of projects since that is not the default way envisioned by the designers, and having an environment that works out of box is so much easier than banging my head against the wall to find usually obscure information on how to compile/debug those app without using the designated IDE.
We could sum things up by saying that editors like emacs / vi implements some of the functionnalities of IDEs by using CL tools (or the libs behind the CL tools).
Your main issue in using an editor as an IDE would be :
configuring it to have exactly the functionnalities you are happy with in an IDE is not necessarily straigh-forward (I ask for sympathy from anyone who ever tried to configure CEDET ;) ), as opposed to working out-of-the-box with IDEs
the way such functionnalities work in editors is very tied to CL, so you need at least a vague understanding of the CL beforehand.
The advantages are the fact that CL tools are sometimes more ubiquitous than IDEs. Also mastering CL opens the door to scripting your build ("make a build in one command" as opposed to "make a build in one click"), which opens the door to automated nighly builds, continuous integration, etc... all of which are harder to setup if your understanding of the build stops at hitting F6 or whatever.
I've spent 4 years developing C++ using Visual Studio 2008 for a commercial company; it's now time for me to upgrade my development process.
Here's the problem: I dont have a 1 button build automation. I also dont have a CI server that automatically builds when a commit happens, and emails me whether a build is broken or not. Worse we dont even have a single unit test!!
Can someone please point to me how I can get started?
I have looked at many many tools and I think I might go with:
Visual Build (for build automation) (Note: I also considered Final Builder)
Cruise (for CI server)
I also now am just starting to practice TDD...so I will want to automate my unit tests as well. I chose Google Test/Mock for their extensive documentation. (Cant go wrong with Google brand can I? =p)
Price is not the issue, I want what's best and easiest to get started.
Can people that use real CI/automation tool for unmanaged MSVC++ tell me their tools and how I can go about starting?
Our source control is Subversion.
Last point: I'm also considering project management/tracking tool that integrates right into VSTD ..and thinking about using OnTime. VSTS costs too much. I tried FogBugz, but I think it's too simple. Any others?
I would take some time to seriously consider TeamCity. We used CruiseControl.NET for a while and TeamCity completely demolishes it. Plus it has built-in plugins for Boost and CppUnit, so your unit testing will come for free.
Best of all, the tool is free for < 20 users and gives you three build agents.
I just finished implementing our C++ product at work and it was fairly simple. We did it with msbuild and basically use the msbuild task to compile the solution. Other targets can be used to copy files, run unit tests, etc.
The last time I worked on an unmanaged MSVC++ project (which was moderately sized I might add), we used FinalBuilder to do the automated build & versioning (and even executing PCLint and other profiling tools as well).
Having said that, if you're willing to invest the time, MSBuild (or nAnt perhaps?) can do everything you need - even for unmanaged solutions.
Which brings us to the trade-off: Tools like Visual Build Pro and Final Builder get you up and running quickly. If you want something which offers a greater range of customization, you'll probably be spending a decent amount of time learning and understanding it - i.e. MSBuild, CIFactory, nAnt etc are no cake walk.
So if price isn't an issue - is time an issue? If time is at a premium, I'd investigate the GUI driven tools, they'll get you to where you want to go quickly. If you know you're going to need to extend on the simple one button build + unit tests + deploy scenario (which happens a lot!) then decide if you can invest the time into the more complex tools like MSBuild?
We use a combination of Boost.Build, NAnt, CPPUnit and either Cruise Control.NET or Hudson (we've used them both for various projects but are starting to prefer Hudson).
They are all good tools though we're considering replacing CPPUnit - the Google unit test system is pretty good from what I've seen.
If you're happy running on just Windows you can lose Boost.Build and just call out to Visual Studio from NAnt.
As for issue tracking/project management we settled on Vision Project after a long investigation. It's not well known (yet) but we've found it a very good fit in our environment. Fogbugz is great, a nice, clear interface but we came to the conclusion you did too; way too simple for our needs.
Although the .NET world is spoilt for these kinds of tools Continuous Integration is still pretty easy to set up for C++! I wouldn't think of starting a non-trivial project without putting these systems in place.
we use subversion + cruisecontrol + wix to accomplich CI automated builds outputting one-click installers. this combo has worked very well for us. we've created out own site for admin of svn user groups and permissioning and added the web interface to cc to it. we have a sql server storing all the collected stats from svn and cc and use them for custom reports available on our site. we are looking to add other tools to the mix for checking various attributes of the code stored in svn. this combo has worked very well for us.
At my company we use CruiseControl (http://cruisecontrol.sourceforge.net/). The Java version, not .NET, to build our wxWidgets application on Windows and OS X. Working great for us so far.
Can anyone list the steps needed to programatically install an application on Windows. Aside from copying the files where they need to be, what are the additional steps needed so that your app will be a first-class citizen in Windows (i.e. show up in the programs list, uninstall list...etc.)
I tried to google this, but had no luck.
BTW: This is for an unmanaged c++ application (developed in Qt), so I'd rather not involve the .net framework if I don't have to.
I highly recommend NSIS. Open Source, very active development, and it's hard to match/beat its extensibility.
To add your program to the Add/Remove Programs (or Programs and Features) list, add the following reg keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PROGRAM_NAME]
"DisplayName"="PROGRAM_NAME"
"Publisher"="COMPANY_NAME"
"UninstallString"="PATH_TO_UNINSTALL_PROGRAM"
"DisplayIcon"="PATH_TO_ICON_FILE"
"DisplayVersion"="VERSION"
"InstallLocation"="PATH_TO_INSTALLATION_LOCATION"
I think the theme to the answers you'll see here is that you should use an installation program and that you should not write the installer yourself. Use one of the many installer-makers, such as Inno Setup, InstallSheild, or anything else someone recommends.
If you try to write the installer yourself, you'll probably do it wrong. This isn't a slight against you personally. It's just that there are a lot of little details that an installer should consider, and a lot of things that can go wrong, and if you want to write the installer yourself, you're just going to have to get all those things right. That means lots of research and lots of testing on your part. Save yourself the trouble.
Besides copying files, installation tasks vary quite a bit depending on what your program needs. Maybe you need to put an icon on the Start menu; an installer tool should have a way to make that happen very easily, automatically filling in the install location that the customer chose earlier in the installation, and maybe even choosing the right local language for the shortcut's label.
You might need to create registry entries, such as for file associations or licensing. Your installer tool should already have an easy way to specify what keys and values to create or modify.
You might need to register a COM server. That's a common enough action that your installer tool probably has a way of specifying that as part of the post-file-copy operation.
If there are some actions that your chosen installer tool doesn't already provide for, the tool will probably offer a way to add custom actions, perhaps through a scripting language, or perhaps through linking external code from a DLL you would write that gets included with your installer. Custom actions might include downloading an update from a specific Web site, sending e-mail, or taking an inventory of what other products from your company are already installed.
A couple of final things that an installer tool should provide are ways to apply upgrades to an existing installation, and a way to uninstall the program, undoing all those installation tasks (deleting files, restoring backups, unregistering COM servers, etc.).
I've used Inno Setup to package my software for C++. It's very simple compared to heavy duty solutions such at InstallShield. Everything can be contained in a single setup.exe without creating all these crazy batch scripts and so on.
Check it out here: http://www.jrsoftware.org/isinfo.php
It sounds like you need to check out the Windows Installer system. If you need the nitty-gritty, see the official documentation. For news, read the installer team's blog. Finally, since you're a programmer, you probably want to build the installer as a programmer would. WiX 3.0 is my tool of choice - open source code, from Microsoft to boot. Start with this tutorial on WiX. It's good.
The GUI for innosetup (highly recommended) is Istool
You can also use the MSI installer built into Visual Studio, it's a steeper learning curve (ie is a pain) but is useful if you are installing software in a corporate environment.
To have your program show up in the Start program menu,
You would need to create folder
C:\Documents and Settings\All Users\Start Menu\Programs
and added a short cut to the program you want to launch.
(If you want your application be listed
directly in the Start menu, or in the programs submenu,
you would put your short cut in the respective directory)
To programically create a short cut you can use IShellLink
(See MSDN article).
Since you want to uninstall, that gets a lot more involved because you don't want to simply go deleting DLLs or other common files without checking dependencies.
I would recommend using a setup/installation generator, especially nowadays with Vista being so persnickety, it is getting rather complicated to roll your own installation
if you need anything more than a single executable and a start menu shortcut.
I have been using Paquet Builder setup generator for several years now.
(The registered version includes uninstall).
You've already got the main steps. One you left out is to install on the Start Menu and provide an option to create a desktop and/or quick launch icon.
I would encourage you to look into using a setup program, as suggested by Jeremy.