Enable/Disable Test Items via Code

Test Items cannot be enabled/disabled via code.  The reason why you have the error when trying to set the "Enabled" property is that it is a read-only property.

Although the error message is not as clear as it could be I already suspected it's a read-only property. It there any other possibility to make the collection of tests which should be executed a bit more dynamic?

This is why I use a data driven structure to drive my tests.  I have a CSV file that gives a list of the tests to be executed and then use a DDT.CSVDriver object to iterate through that list and execute the tests.



In doing so, I'm not actually using the "TestItems" part of the project, I have one TestItem to run the CSVDriver iteration and then use code to read from the driver what needs to be run and execute those things (scripts or keyword tests) accordingly.

How do you actually run a test referenced by a line in the CSV file?



I found a similar solution: I don't iterate over a CSV file but the TestStructure. I disabled all top level items but the one which iterates over all others. I can now apply as much logic for each test item and than decide to run it or not. To run a test I call "eval(scriptName)" or "Runner.CallMethod(scriptName)".

Using Log.AppendFolder I can structure the log so I can distinguish which test is run. It's nearly what I want, but the execution summary is not as clean as I'd like. TC shows a nice summary of the test run, but now as all tests are merged into one its nearly useless. It also slows down Internet Explorer when viewer the exported (mht-)log  file because one entry gets huge. I would really like to create "Log Items" myself to structure the log. Is there any possibility to do that?

The way I have it set up is described in this article...



http://blog.smartbear.com/post/11-07-11/automation-framework---a-new-table-driven-technique-using-testcomplete/

Is the code for your framework available somewhere? Maybe I'm blind, but I didn't found any download link. I'm especially interested in how you actually execute a test and how the log look like.

I can easily supply it.  Drop me an e-mail and I'll send you the relevant files.  My e-mail should be linked from the article.

Thanks. Unfortunatelly I didn't found any magic tricks in your code ;-) You execute the tests via Runner.CallMethod and organize your error log via Log.AppendFolder. With the same disadvantages my own "framework" has.

I think TC needs improvement here. 

The "magic" is that the Runner.CallMethod doesn't actually call the specific code methods for executing tests but simply calls an "Execute" method that is named as <AUTName>TestStep.Execute.  That method contains a case statement that parses keywords for the execution.  There is no "code" referenced in the CSV files, simply a set of keywords that feed into the loop for creating the array.  Code routine calls are constructed on the fly.



If, in the CSV file for the list of tests the first character is a "semi colon", it skips that entire test.



So, where in your framework you have (at least as I under stand it) your CSV file containing specific code routines, I have two CSV files.  The first is  a list of test cases with simply the test case ID and a descriptor.  The second is a list of steps organized by test case ID containing a step counter, the AUT name against which the step will be executed, a keyword designator for the step, and a delimited string for any specific detail data needed during executing that step.  



As for large logs, the framework is designed that you can drop in different pairings of the two CSV files for different sets of tests.  Rather than having to execute ALL your tests in one project run, you simply designate the project to run with one set of CSV's, copy in another set, run that, and repeat.  You'll get a lot of smaller, more easily handled logs that are specific for certain desired testing outcomes.



(shrug) YMMV but I find this an efficient way of constructing tests where, if I need to add a new test case, at minimum I simply need to add more records to the CSV.  If the new test case involves new features of the AUT, then I need to add a bit more code but, again, modularized based upon AUT and controlled by the case statements.