Forum Discussion
Hi,
What you need is absolutely possible without any specific actions from your side.
TestComplete communicates with desktop applications as with Sys.Process(<WPF app>) objects and with web applications as with Sys.Browser.Page(<Web App Page>) ones.
Your tests can address both your applications and TestComplete will switch and drive required application automatically.
- endorium7 years agoFrequent Contributor
So I dont need to combine both projects/frameworks together then?
For the WPF scripts the dictionaries/mapping etc... will be in the WPF framework.
I will be in the Web framework when I execute a test. We use workbook driven tests for both web and wpf.
- AlexKaras7 years agoChampion Level 3
> So I dont need to combine both projects/frameworks together then?
Well... You do need to combine them to certain extent...
But the implementation depends on your test plan.
For example, assuming that you need to run tests against your WPF part and then run tests against web part, then all you need to do is to create a new test suite, add WPF project to it, add web project to it and run the whole test suite.
If you need to do something in your web application, then do something in the WPF one and return to web afterwards, then you need to make web tests access test code for WPF and vise versa. To do this, you can, for example, create a new test project and add WPF and web test and framework script units to it as existing modules. If your test code uses NameMapping/Aliases then you will need to merge namemapping files from both frameworks and add resulting file to the test project.
Namemapping will be the only inconvenience because while regular script code can be shared between different projects, namemapping cannot be dynamically combined. Thus, if your namemapping changes, you will need to copy changes from one file (web or WPF) to combined file (or vise versa, depending on what file was changed).
Related Content
- 4 years agoAutomation1id
- 4 years agonedbacan