Forum Discussion
Hi Alex,
Now I changed the Connected App scenario, I put my code in a VB.Net Dll, and I added the Dll in TC using CLR_Bridge. It was successfully registered in, I write following code
Sub TstXlsRdr
Dim p
p = dotNET.CMSIntergrationLib.DriverTC.ProcessBatchFile("D:\TestComplete\BatchRN2.xlsx", "CTA")
End Sub
The subroutine reads an excel file successfully, Connect.Log.Message can also successfully write the strings in TC log. But as I try to read following statement it give error [Object variable or With block variable not set]
Private Function CheckRegApps(appName As String) As String
Dim AppName As String = appName
Dim tstAppObj
Try
tstAppObj = Connect.TestedApps.Items(AppName)
Catch ex As Exception
Throw ex
End Try
End Function
What is wrong with this code, looks like tstAppObj is unable to get TestedApp type of object.
I am new to TC environment, please need guideness in this matter.
Hi,
Can you describe for what and how you are going to use TestComplete? What type(s) of tested application(s) are you going to work with?
The case is that the initial idea and the purpose of Connected applications support in TestComplete was to provide support for self-testing applications while make it possible for them to use some functionality of TestComplete in order to not invent the same just for the testing purposes. For example - use test log provided by TestComplete and not create custom logging.
Self-testing applications are applications that do some test actions from within their own code using full access to application's code - a kind of highly extended unit testing. For example, your application, if started with some additional parameter, may expose additional toolbar with buttons that trigger some business workflows that regular human users are expected to follow, but without user interface and additional messages (like 'Do you really want to delete this order?').
Considering the above, some functionality provided by TestComplete may be irrelevant for self-testing applications and might be not supported. (This should be checked with TestComplete's documentation.) For example, what for your self-testing application might need to get the list of the Tested Applications from TestComplete's project while it (application) is already running and has all information about itself?
If for any reason you need to have self-testing application then, as I wrote it in my initial reply, I would recommend you to consider TestLeft as it better suits this testing scenario.
The primary area for TestComplete is external control of the tested application from the point of view of the human user. This means that (primarily) TestComplete has no idea about application it will drive. That is why this is specified as the Tested Application. When TestComplete starts the Tested Application, it analyses started application in order to control it more efficently. In certain cases, it is possible to call native internal public methods of the tested application from TestComplete's test code, but this is an exceptional case, not the usual recommended approach. The usual approach with TestComplete is to emulate end-user's actions via sending operating system messages to the tested application (like type some keys, click mouse button, etc.) like the human user, who has no access to source code and application's internals, does.