Sectionalized, Distributed, and Automated Testing

Question

I'm part of a group in our company that's trying to rethink and consolidate our large base of TestComplete scripts into something more manageable. And there have been some frustrations along the way that really should be given higher consideration from the developers of TestComplete (some things that would easily resolve our challenges were suggested years ago and still are not implemented).

We're trying however to segment our tests to separate branches, ie "Bugs", "Tutorials" (to make sure our instructions given to end users in video and pdf tutorials still work), and so on. Part of the goal in this is that our logs will be smaller, TestComplete will have a lower crash rate, and we can streamline more pointed integration with our build servers.

The easiest way, it seems to us, would be if TestComplete allowed us to execute a project's test group from the command line (would this really be *that* difficult to implement?) This was suggested back in 2012 here but still isn't implemented (by the way the links Tanya posted are broken now).

So we considered breaking it up into seperate projects. One for Tutorials, one for bugs, one for source coverage, and so on. We ran into a problem in that we can't share the same .tcEvents, .tcScript, .tcStores or .tcTAs files between projects in the same suite (apparently almost all your tags in your configuartion files are given unique identifiers and can cause conflicts if loaded twice in the same suite - side note: *Do you really need to uniquely identify **everything**? This kind of environment seems excessively and unnecesarily restrictive to me...*).

Furthermore, continuing along this thought, if you clone a project that links to an external .tcScript or other similar project file it will reference the same one, (what we want to be able to do by right clicking a fresh project and using "Add Existing"). However, when you open the project suite the next time you will receive a fatal error because two objects have the same key in the project suite. (This is a *bug*)

We're not sure what else to do for organization beyond writing our own external scripts to modify your configuration files before executing a project (a royal pain - what with all your unique identifiers, which otherwise would be a minor annoyance), or manually adjusting the projects to run targeted tests (which defeats the purpose of integrating with our build servers, or rather to say instead it makes it impossible to do so).

What we'd like to see happen:

Give the afore mentioned request an increased priority [top priority? pretty please? :)], it would really be by far the *easiest* for you to implement, and for us to implement.

Allow project items to be shared between projects in the same suite. This likewise, shouldn't be too dificult, though obviously a little more involved than the previous solution. Regardless of the afore mentioned fix, this should be implemented anyways.

Allow tsScript files to reference/include other tcScript files. This would allow us to go back to using a split project structure that references necessarily shared code, but not duplicating test items from other projects and not causing TestComplete to load *very slowly* and sometimes crash.

In the meantime if there are other solutions you could reccomend we would be happy to hear them. Our work on this task is being postponed for a *short* while so we can get some other important things done.

hlalumiere · Answer

I think the main problem is the way TC is getting targetted at a general audience. TestComplete would love to put up a sign saying "you don't need to be a programmer to use our test suite", so the software gets dumbed down and "simplified", but the reality of it all is that 99.9% of test engineers are programmers. And those programmers are missing the features you decided to strip out or not put in because they were "too complicated".

TestComplete is not Microsoft Word. It's a tool for programmers, I wish the bears would finally get it and stop trying to make it something it's not. Programmers don't need pretty UI's, or animated windows, or auto-complete that looks pretty but doesn't work half the time. Programmers need something functional, flexible, and fast.

In the meantime, I think your only recourse is to use COM and build a controller that works for you. I highly recommend using a SQL database to organize it all, that your controller can chat with and do its thing. This is what we did here and it works pretty well. Ironic how the UI designed for 10 year olds forced me to write a whole set of applications to be able to do what I needed to.

The reality of it is a lot of things need to go from TC before they can even think of implementing what you suggested. The project file format needs to go (use proper XML that's why it was invented), the results format needs to go (storing data as HTML and images is nuts!), the current COM interface needs to go (it's ridiculously useless, it does about as much as you can do just from one toolbar in TestComplete), the UI needs to go (it's slow, bloated, and buggy), etc etc.. Really the only thing that makes me love TestComplete is the Object Browser and the test engine itself, most of the rest is rubbish at best.

tanyayatskovska · Answer

Hi, &nbsp; I've added your vote to the suggestion to implement the ability of executing a bunch of test items.&nbsp; At the moment, you can use the script I posted here for this. &nbsp;

wmsbuild · Answer

I agree with you in a lot of ways. I think changing the mindset of TestComplete in that way would be beneficial. I don't think it's a prerequisite though, at least not for the first suggestion (I can see where it would become a problem for the latter suggestions).

Where you can right click on a test group and run a focused test it should just be a matter of calling that function from the command line.

We've played with the idea of modifying the config files to tick test groups on and off (a small change that would be relatively easy). For now we've decided it best to consolidate our shared code. If there's more than two or three scripts we might want to rethink what code is being shared anyways (that is in our circumstance, other circumstances might simply need more sharing).

Still would be nicer if we could do things with one project and executing seperate test groups. And if it would load smoother even have all three of our platforms in one project suite (but that's too much for TestComplete in it's current state.....)

glarsen_1 · Answer

Tonya,Thank you for helping us out with this. We really appreciate it as our test suite is rather large and i don't want to redo everything. I was able to take a look at the function you used to call a test group, but we are using visual basic. Do &nbsp;you have an example of the same script in VB? Thanks for your help.

tanyayatskovska · Answer

Hi Tester, &nbsp; Actually, you can use this sample as it is. The js file (where the whole sample is located) is executed via Windows Script Host (WSH). You only need to pass the needed command-line parameters to execute the file.

Forum Discussion

Sectionalized, Distributed, and Automated Testing

5 Replies

Recent Discussions

ADO Pipeline Execution Fail issue after TC\TE upgrade

RuntimeError: The object does not exist

Fields data to compare?

Related Content

Anybody did build installation automation for distributed system

Stop Skimming PDFs, Start Automating PDF Testing

Groovy Automated DataSource Loopers