Alex,
Thanks for your comments.
1.
I was not clear enough.
I don't expect that each "var" object will become typed object, and it will show me Click method if it only exists.
My concern is that I cannot count hours that me or people around me spend to find the "typo", when after several ours of debug you are becoming some how blind and simplest mistake become error.
Extensions at least now, does allow to avoid this instead of:
["Exist"], ["Eksists"] and etc,
now I can just type Exists().
AutomatedQA.TestComplete.CSConnectedApp for sure can have these extensions at least for basic functions (don't ask me what is basic) :-)
Maybe there could be set of extensions... E.g. linq has data, enum, xml separate extenstions, and maybe the same can be done for test complete.
2.
Honestly Exceptions in connected app is not only issues that we had to found workaround. It was a challenge to make "UiBaseTest" to make Ui test work under NUnit more naturally.
I think I'll need to make an article about this challenges :-)
3.
I would not say I'm untypical... In Ukraine community of automation testers I know dozens of testers with Developers background. Also I see popularity of selenium because it can "easily" work as API, because FireFox's IDE is quite limited. And I see plenty of articles about suggested tests architecture for Java/.NET using PageObject, Facade, Chain, Singleton, Factory and etc patterns using Selenium.
And customers are interested to build team with manual testers in soul and take "Developers in test" just to perform tasks of automation.
If I can vote somewhere and my colleagues can vote too, TestComplete API is for sure is are of improvement.
4.
>>When
developing the concept of Connected Applications, we expected that users
would record (or create) C#Script code in TestComplete and then copy it
to C# applications, but not write test commands from scratch in Visual
Studio IDE. :-)
Alex, let me join to discussions... :-)
In time pressure it was easier to us understand more what developers does, and what are benefits in MVP architecture (my biggest project based on). And we found interesting applying approach of Automation Pyramid
<Manual>
/GUI\
/ API \
/ Unit \
And also taking in account that from native (in my case .NET, MS Studio) ide it is easier to get access to Domain, without need to do manipulation with UI, and in the most cases it is reasonable by required time to prepare environment (direct AppServer calls in hundred times faster than UI).
Our tests look like:
SetUp: Do something with Domain
Test: Login, act and assert on UI that it is ok. (For async UI it is: navigate to UI, simulate Domain calls, assert on UI)
TearDown: close UI, remove created objects
So it is more naturally to write tests from "scratch" using Framework.
And be honest my project is not alone in a such approach. And some WPF based projects have selected CodedUi.
P.S. I have sent in Support "Idea".
P.P.S. skype me: makh_dv, if we can do something more in this direction.
