Finally we get to the point where we can start looking at the creation of automated tests with Keyword Testing in TestComplete. We’ve looked at some of the key components like Managing Projects, Options and Settings. We’ve also seen how Objects, Properties and Methods are critical to the tests you write. All of these components and concepts are part of the foundation you need in order to start creating automated test cases. You have that foundation now. From here on in it’s all about creating tests.
You may or may not have figured out that you have two ways to create automated tests in TestComplete. Scripted (e.g. Python, VB, Java Script, etc) or Keyword graphical drag and drop. We’re looking at creating Keyword tests here but if you’re keen to jump ahead you can record Scripted tests by clicking on the ‘Record Script’ button. Scripts you record are then stored in the ‘Advanced’ folder under the script element in the file or unit you chose.
Anyway, that’s not why we’re here. We’re here to look at keyword tests. This is the graphical, drag and drop approach to creating tests. There are two ways to create these types of tests.
1) recording tests (either appending or creating new)
2) using the operations panel to build or modify your tests by hand
The record approach is straight forward enough. Click the record button, complete your actions on the application under test and stop recording. Then view the test items/steps listed in the Test.
Whilst that’s the simplest way to go about it you’ll probably learn more about what’s going on if you build your tests from the Operations panel. Certainly if you want to modify and manipulate existing tests then learning to use the Operations panel is going to be important.
From the operations panel you have the ability to add all sorts of operations or actions to your tests. Just drag and drop the operations into the appropriate parts of your existing tests. When you take this approach you see what makes up a test item/step in more detail. For example one common operation you’ll work with is the ‘On-Screen Action’ operation.
When you drag this item onto your test you’ll be taken through a few steps:
1. Select object you want to interact with
2. Select method you want to call for object
3. Specify the Values or parameters required for the method
It breaks down quite simply to selecting the object you want to interact with, specifying the action/method you want the object to carry out and then define any values/parameters required (this might be the coordinates you want to click a button at or the text content you want entered in a text box).
Once you’ve gone through this it’s easier to understand the data displayed on the test case work-space for each of the test items/steps.
For each test item/step you see the columns:
1. Item or Name of the object you want to interact with
2. The Operation / method or action
3. Time you’ll wait for the object to be displayed (optional)
4. Parameters and/or values to use
5. Free format text description
All of this information is displayed on the ‘Test Steps’ tab in the Test Case workspace. You’ll also find tabs for Variables and Parameters that can be defined for a Test Case.
Variables contain values that can be used at run time and that can be changed at run time (e.g. whilst the test is running). So for example you might set a variable that’s used to count the number of times that you loop through steps repeatedly in a test. There are many uses for variables but the important thing to remember is that they are set when you are running the test and can be modified during the execution of the test.
Parameters can be thought of as values that are fed in at start of the test execution. They are not modified during the running of the test. Just set at the start and then used during the execution. Typically you might have a test that has parameters and then call the same test multiple times, each time with a different parameter value. So you follow the same test steps/actions each time just use different values each time you run the test. Just remember that Parameters are fed in at the start of the test and don’t change whilst the test is running.
Those are the key concepts to grasp when creating keyword tests. Either record your test steps or build them up using the different operations from the operations panel. Each test step has an object it interacts with (i.e. a button object), an operation or method that it completes (i.e. clicking the button). Sometimes there’s also a value that is set (i.e. entering a text string in a text box).
As part of the test you can also set variables and parameters. Variables are values you can use during your test run and values that you modify at run time. Parameters are values that you feed in as you start your test. So you can run the same test multiple times with different parameters. Parameters can not be changed or modified during the run of the test.
Remember those concepts and everything else will start falling into place as you build more and more complex test scenarios. In the next module we’re going to look in a little more detail at Projects and Project suites. We’ll also see in the next module how we can utalise the power of test case Parameters at the project level.
We covered Options and Settings in the last module (Module 5). Whilst there are probably over 100 options and settings we’ve focused on the most important ones you’ll need to know about as you start out with TestComplete. Probably a bit of a tall ask to remember all of the settings we covered there. However, if you just get a feel for the key settings and project properties it’ll make your life easier as you progress with implementing TestComplete. What you will need to grasp in detail though is an understanding of Objects, their properties and their methods. And it’s Objects, Properties and Methods we’re going to take you through below.
If you don’t grasp the concepts of Objects and Methods you’re not going to get far with TestComplete. It’s absolutely critical to grasp these concepts. These are concepts that go much wider than just TestComplete. Grasp them though and a lot of TestComplete concepts will fall into place far faster.
If you’re wondering what Objects and Methods are in the first place then here’s a repeat of our very basic overview (from Module 1). You can skip this if you’re already happy with these concepts and move on to how to work with them in TestComplete if you’d prefer.
Objects can be thought of as processes, applications, windows, browsers, etc that are present on your system. They are things that are present on your system at any point in time. Some of these objects may be visible on your system (e.g. a window displayed on your desktop) or they may not be visible (e.g. a process running in the background). All objects will have properties and methods.
Properties can be considered as characteristics of the object. For example you ‘System (sys)’ object will have a property called ‘Hostname’. That property would have a value (e.g. The host name of your system).
Methods can be considered as actions that the object can carry out. For example if you have the CalcPlus application/object running on your system, this object could have the ‘close’ method. If this method is called then the object would be closed on your system.
If you’re still struggling with the concept of objects, properties and methods read the following analogy (slightly daft analogy but hopefully gets the point across):
Objects and child objects: You can think of yourself and your body as an object. As an object you have lots of child objects. You have a head, you have arms, you have legs, etc. These child objects have their own child objects. For example an arm has child objects like shoulder joint, elbow joint, wrist joint, forearm, top arm and hand.
Properties: Each object will have a number of properties. You have a height property. That property could have a value (for example 1.6 meters). You body will have a list of properties and each of it’s child objects will have it’s own list of properties too. Take your ‘arm’ object. We’ve seen that the arm has a list of child objects. The arm itself could then have a property called ‘Number of child objects’. The value of this property is 6 (the six child objects for the arm being the shoulder joint, elbow joint, wrist joint, forearm, top arm and hand). Other properties for the arm could be things like colour, texture, etc. All of these properties could have values.
Methods: These are the actions that the object can carry out. Your overall body object might have methods, or actions, like Sleep, Run, Walk, etc. Each child object may have it’s own set of methods too. So your arm object may have methods like bend, twist, raise, lower, etc
These principals apply in exactly the same way to everything on your computer or laptop. The top level object can be considered your computer system. This system has child objects which might be processes (like the notepad process running on your system). The notepad process then has child objects which can be windows that are displayed on your desktop. If we take the notepad window this window will have properties; like height, width, colour, title, etc. This window will have methods too. These methods are likely to include actions like ‘minimise’ and ‘maximise’.
First off it’ll help if you know what the object browser in TestComplete can do for you. The object browser is TestCompletes view of your system. It’s how TestComplete see the structure and relationship between those objects. And it’s where TestComplete shows you the different aspects of those objects (their properties) and what those objects can do (their methods). All of this information is displayed and interpreted with a few key panels in the Object browser view. Those key panels are:
The Object Tree shows the list of objects, their relationships and hierarchy. Everything starts at the top with the ‘Sys’ object which represents your PC or Laptop System. Everything else is a child of this Sys objects. Child objects are either Processes, Windows or Browsers. Typically under the Sys process everything will be a process (e.g. your Calc process) and then under this the Calc process will have a load of window objects. It’s these window objects that are usually displayed on your desktop.
When you click or select an object the panel on the right allows you to look at the properties and methods for that object (selectable with the tabs). The Properties tab lists all the properties associated with the object you’ve selected. Properties can be read-only or read/write. If you see a little ‘o’ symbol next to the property then this means its a read and write property. You can actually click in the property value text box and modify the value (that value then reflected and changed in your application).
The methods tab lists all the actions that the object can carry out. Actions typically include things like click, focus, drag, etc. All the sorts of actions you’d carry out when you’re working with your application. You’ll also find more obscure methods that are specific to different object types. For example the Calc Plus process object has a WaitSwingObject method. I’ve no idea what that method does. And this highlights a good point. Each object will have a lot of methods. You’ll probably only find that you need to use 4 or 5 of those methods. There’s no point becoming familiar with all the different methods, just get familiar with the core methods. Which brings me on to the next point…
You’ll notice when viewing properties and methods that there’s a link to view more members (advanced view). TestComplete hides a lot of the properties and methods that it doesn’t think you’ll be interested in. However, if you need, or want, to see everything then click this link. You’ll see 10 times as many properties and methods for the object that you’re looking at. Best to stay in ‘Basic’ view for now though.
Another useful thing to know is the object browser context menu. Right click on an object and you’ll see a context menu with lots of useful options. These include:
Refresh – Reloads the object tree.
Map Object – Name Maps the selected object.
Show Object in Name Mapping Editor – Navigates to the Name Mapping Editor and selects the current object.
Store Object – Saves the object and its children in the Store.
Highlight on Screen – Places a highlight border on the selected window if the window is visible.
View Object – Captures a window in the Image Viewer.
Add Process to TestedApps – Adds the selected process (or parent process if a window is selected) to the TestedApps node.
Terminate Process – Immediately shuts down the selected process (not recommended)
Copy – Makes a copy of the text for the selected node in the Windows clipboard.
Panel Options – Navigates to the main menu’s Tools | Options page for the Object Browser.
Whilst we’re looking at objects and methods it’s worth saying a little bit about object naming conventions in TestComplete. In it’s simplest form we just need to use ‘dot notation’ to describe the path from the top of the object hierarchy down to the object we’re interested in.
For example when we’re looking at the full path to an object we’ll start at the top of the hierechy which is the Sys object. Then we’ll pick the next object down and add that to our path notation with a dot separating the two objects. Then repeat. So we’ll end up with something like this…
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Static”, “”, 2)
Okay so that looks a little more complicated than I made out above. Let’s break it down.
If we start out like this…
Then all we’re talking about is starting with the Sys object, then below that there is a ‘Process’, below that is a ‘Window’ and below that is another ‘Window’. However, if we take it like this you’re probably thinking there’s a lot of objects in my system that could match that naming. Word or Excel for example are processes running under the system object that have a window and underneath that another window.
If we were to use this naming convention we wouldn’t be able to uniquely identify an object. What we need is to fill in some detail in the brackets that narrow down what we’re trying to identify. Take this bit…
Well that uniquely identifies the ‘CalcPlus’ process running on our system. That helps. Except it doesn’t help if we have more than one instance of CalcPlus running. In that case we need to identify the CalcPlus object with a unique index Id too. If we had two open instances of CalcPlus we’d see something like this…
You can see here that with two instances of CalcPlus running we’re uniquely identify the two different instances with an attional attribute in the brackets which identifies the instance by an ‘index’ value. Index value 1 for the first instance (which isn’t needed in the brackets) and index value 2 for the second instance.
As we take this a step further down the hierarchy we’re using exactly the same principals. In the brackets define some properties of the child object that help to uniquely identify the object among other similar objects.
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1)
So in this case we identify the “Window”, that’s a child of the process, by using the property of the window which is ‘SciCalc’. We also use a 2nd property that contains the value “Calculator Plus” and the “1” which indicates the index (or instance) of CalcPlus that we’re running. All of this together means we can uniquely identify this window amongst other windows that might be similar.
We can just keep going with this process to identify another windows under this with the following…
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Static”, “”, 2)
Now we see another final child object, again a Window object, identified with some unique properties (“Static”, “”, 2).
Everything we’re doing here is based on meeting 3 key criteria to identify the object:
1. identify the object hierarchy (e.g. to find a specific object you need to identify the parent objects)
2. identify unique properties of that object (e.g. the WndCaption property which could be ‘Calculator Plus’)
3. and if that still doesn’t uniquely identify the object (because there are identical objects at the same level in the hierarchy) then use an index value to pick out the correct instance of the object.
So this provides us a way to uniquly refrernce objects and a naming convention that allows us reference those objects in our scripts. For example if you want to click the a button in CalcPlus you can define the button object name with this….
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Button”, “2”, 11)
And then to click the ‘2’ button add the click() method to the end…
Sys.Process(“CalcPlus”).Window(“SciCalc”, “Calculator Plus”, 1).Window(“Button”, “2”, 11).Click()
or even if you script it in a Python script you can do something like this…
Try it. As long as you have CalcPlus open you’ll be able to identify the object and click it.
Just to take this a step further you ought to be aware that this is just one way of naming your objects. There are two others. We can refer to this one as …
1. The ‘Sys.*’ naming convention
And the other two ways are….
2. ‘NameMapping.*’ naming convention
3. ‘Aliases.*’ naming convention
All are legitimate ways to refer to objects in your scripts. We’ll talk about the other 2 (Namemapping and Aliases) in later modules. Grasp this first method and understanding the other two will come quiet easily.
We made our way through Module 4 which covered the fundamentals of managing projects. Now we move on to look at some of the important options and settings you’ll find in TestComplete.
When it comes to options and settings in TestComplete there are 4 distinct areas you need to know about. These areas are:
Options: [Click ‘Tools -> Options’ in the TestComplete menu bar] the settings that configure how TestComplete works and operates. These are like global settings that affect your general usage of TestComplete. They are independent of projects so that the options you select will apply regardless of the project that is open.
Project Properties: [double click the ‘Project’ node in the Explorer then select the ‘Properties’ tab at the bottom of the Project Workspace] these are settings that apply ONLY to the project that you are setting them for. So each project you open will have the same set of properties but you can set the values independently for each different project.
Project Suite Properties: [double click the ‘Project Suite’ node in the Explorer then select the ‘Properties’ tab at the bottom of the Project Suite Workspace] these are settings that apply ONLY to a Project Suite (remember that one Project Suite can contain one or more Projects). Each project suite will have the same set of properties but again you can set the values independently for each different Project Suite.
Default Project Properties: [click ‘Tools -> Default Project Properties’ in the TestComplete menu bar] when you create a new project it picks up a set of ‘default project properties’. It’s the same set of properties that every project contains. You can just think of the ‘Default Project Properties’ as the template that every new Project bases it’s initial Project Properties on.
That’s the four different areas of settings, properties and options you’ll find within TestComplete. In the next few paragraphs we’re going to highlight the most important of these. There are literally hundreds of others that we don’t mention here, but the ones we do mention are the ones you’ll find yourself coming back to time and time again.
Engines/Log/Activate after test run – Automatically opens the test log tab when a test run finishes. Switch this off if you get annoyed at always been shown the log file at the end of a test run.
Engines/Log/Open logs in the same panel – un-select this and TestComplete will open every Log file in a new tab. Usually best to keep this option on so that TestComplete only displays one set of logs at a time.
Engines/Log/Show Log on pause – if you’re in the middle of a test run and pause the run this option allows you to display the log file during the pause.
Engines/Log/Store all logs – You can get TestComplete to delete some log files automatically (useful as they do tend to build up). Or alternatively you can opt to keep all your log files and delete them manually when you don’t need them.
Engines/Name Mapping/Update Name Mapping during test run – if TestComplete cannot identify a mapped object during the test run then it’ll try to add an entry automatically
Engines/Name Mapping/Map object names automatically – Automatically generates custom names for objects that you are working with where they have not yet been mapped.
Engines/Name Mapping/Use extended find when possible – tell TestComplete to look down through the hierarchy of objects if it can’t find an object at the level it first expects to find it at.
Engines/Recording/Automatically add applications to the Tested Applications list — automatically add applications started during recording to the Tested Applications list of your project.
Engines/Recording/Always start a new test – start a new keyword test or script routine when you initiate recording by selecting Record Keyword Test or Record Script on TestComplete’s toolbar or main menu.
Engines/Recording/Real-time mode – record the actual time intervals passed between user actions and insert them into the recorded test as the Delay operations
Engines/Recording/Record text input into simple editors as – TestComplete can enter text into your application in two ways. Keys which simulates you typing in the object. Or just setting the text property of the object. Pros and cons to both (which we’ll discuss later). If in doubt chose Keys.
Source Code Control – This allows you to configure integration with source code control tools like SVN and Git. Thus you can make sure all your project artefacts are maintained in a controlled manner. Check out on open, Check in on close, Bind new items to SCC, Show provider messages and SCC provider all options you can configure.
General/Record user actions over tested applications only – Make sure TestComplete only records actions on applications that are in the tested applications list.
PlayBack/Stop on error – Execution will end the moment an error condition is encountered and an error message written to the TestComplete log file
PlayBack/Stop on warning – Execution will end the moment a warning message is encountered and a warning messages written to the test log.
PlayBack/Error dialog – If this option is enabled, TestComplete will ask whether to stop the test run on critical errors.
PlayBack/Disable mouse – Disables the mouse before playing back script. Pressing Ctrl + Alt + Del enables the mouse.
PlayBack/Auto-wait timeout, ms – Milliseconds to wait for an expected object to become available, or for an unexpected window to close, before posting a timeout error.
PlayBack/Delay between events, ms – Milliseconds of delay between each command during execution.
PlayBack/Key pressing delay, ms – Specifies the number of milliseconds between each key press event.
PlayBack/On unexpected window – What to do if an unexpected window shows up during play back (options include Ignore unexpected window, Stop execution, Click on focused control, Press Esc or Press Enter).
Project Suite Properties
The only option found here currently is the definition of the location that TestComplete should write the Project Suite execution log files to. Not really worth worrying about as the default setting here is rarely changed.
Default project properties
As already mentioned these properties include settings that are used by default for new projects and project suites created in TestComplete. The key settings and possible values are the same as discussed in above under Project Properties.
These are the core properties and settings that you’ll find useful when you start out with TestComplete. It’s worth becoming familiar with these as they will help you run your project smoothly. There are lots more to discover but stick with these to start with until you’re ready to go further.
In the last module, Module 3, we looked at the TestComplete user interface. In this module we’re going to look in detail at how TestComplete manages projects and projects suites. In TestComplete there is a hierachy of items that you’ll create and work with as you implement your automation project. That hierarchy starts at the top with the ‘Project Suite’.
The Project Suite is just a container for 1 or more projects. Each project being a distinct group of test items that go together to make up a particular test automation effort. For example you might have an application to test that has, desktop, mobile and web client applications. It may also have a server component that’s accessed via an API.
In this example we’ve used TestComplete’s Project Suite to cover all the automated testing of one particular application that has a number of different components. Within the Project Suite we’ve created separate projects for the desktop, mobile, web and Api components of this application. You could even create another project that covers integrated testing across all 4 of these applications.
The key thing to remember is that each TestComplete project suite can hold 1 or more TestComplete projects. Each project is a container for the test components and artifacts needed to automate the testing of a distinct aspect of your application. Grouping projects into a project suite allows us to reuse artifacts across different projects whilst isolating the test effort for a particular aspect of our testing into neat manageable project containers.
Each project will contain all the elements you need for a specific test effort. By default those elements include:
Project: the project node, when opened in the workspace, allows you to select which tests to run within the project and set project properties (e.g. enabled screen captures during test replays).
Advanced folder: in here you’ll find your scripted (e.g. Python) tests and other more advanced project components. Components like Events or Low Level Procedures. This folder is really designed to hide some of the more complex project elements whilst you get started with TestComplete.
Keyword Tests: Your automated tests.
NameMapping: a list of the objects in your application under test that you want to interact with. The Name Map allows you to specify the properties you want to use to identify those objects too. Much more on this later.
Stores: a container for lots of other objects you might need as part of your test automation project. For example objects to connect to databases, containers for storing images and containers to store files you might need to do comparisons against.
Tested Apps: this project object allows you to list the applications you are writing automated tests for. This helps because you can tell TestComplete to only focus on these applications during development and execution of your automated tests (and this helps because TestComplete then hides all the other unimportant stuff from you – to keep you focused on what’s important).
Lets look at the Project Suite entity in a little more detail then. To configure the Project Suite, double click project suite node in the Project Explorer. This gives you a list of Test Items for the suite. When you ‘run’ the suite, what you’ve selected here gets run. You want to run a series of Projects in turn? Select each of those projects here then run the Project Suite. TestComplete will run each project you’ve selected one after the other.
In the same vein if you double click on the Project node, open the project workspace, you’ll see a list of Project Test items. When you ‘run’ the Project, it’s the selected items in this list that get executed. You can add tests to this list of ‘Test Items’ just by dragging Key Word tests and scripted tests into this workspace.
So we understand the concept of our test elements, all of which are listed in the Project Explorer. And we know that it’s that list of Test Items that gets executed when we run our Project. What if we want to do more than just run Keyword tests and/or scripted tests? Well TestComplete gives you a lot more capabilities that aren’t immediately visible to you. In the Project Explorer you can add other types of elements and test items to your project.
Right click on the project and select ‘Add’ followed by ‘New Item’. From here you’ll get a list of other project items that you can include in your project. You add other test elements like Manual Tests, Events and Low-Level Procedures. Each element giving you a new capability within your test project.
As well as adding you can remove and delete too. If you right click on an existing item and click on remove you can remove or delete a project element.
There is a clear distinction here. When you get prompted to ‘Remove’ or ‘Delete’ these options do very different things. Remove just stops displaying the item in your ‘Project Explorer’ view. The related files on your computers file system still exist. Once you’ve removed you can add ‘Existing’ items to include the item back in your project at a later date.
If you choose ‘Delete’ it does what it says. Not only does it remove it from the ‘Project Explorer’ view but it deletes the assoicated files on your computers files system. You won’t be able to add these items back into your project ever again. Gone for good they are.
This same concept applies to the Project log files. Here though you may well want to delete log files for good. As you run your tests log files build up over time and you’ll want to purge and delete many of them.
Again though, if you want to keep the files and only remove them from the displayed list in your Project Explorer then select ‘Remove’. Then you can add them back in later if you need them. If you don’t need them any more (ever!) then select delete.
Next up, Module 5, where we look at some of the more important options and settings you’ll find in TestComplete. There are millions of settings and options (slight exaggeration) so we’ll only focus on the important ones for now.
In module 2 we looked at creating our first key word automated test project. In that module we touched on a number of key areas of the user interface like the Project Workspace and the Object Browser. Each of those key areas giving us the ability to develop our tests and examine the applications we’re testing.
In this module we’re looking at some other key aspects of the user interface. Key components that you’ll find yourself using on a regular basis to help you develop, debug and run your automated tests.
In the next few paragraphs we’ll go through some of the most useful components within the user interface.
First up then the view menu. In here you’ll find the ‘Select Panel’ option. This option allows you to select which panels you want to display in the TestComplete user interface.
One useful panel is the Properties panel that shows you the properties for each of your test items. For example you can pick a test item, like a keyword test, and see the path and file name to the keyword test on your file system. Useful if you want to back up a particular file. Or if you just want to find out where the complete project suite is located on your file system.
Next then the object spy. This allows us to identify objects in our application using a cross-hair and then inspect their properties and methods.
You can either drag the cross-hair over to the object you want to look at. Or you can use the ‘point and fix’ method (put your cursor over the object and press Shift + Ctrl + A). Once you’ve picked out an object you can see the full name for the object, a list of the methods and the properties for the object (more on methods and properties back here).
One key feature here (pretty innocuous but very very useful) is the highlight in Object Browser button. Once you’ve identified an object you are interested in click this button and the object will be shown in the object browser. This is useful because you’ll get to see the context and position of the object in relation to it’s parent and child objects. That might not seem important now but it does become absolutely key to getting a good feel for the construction of the application you’re testing as you progress.
Next up then is the Visualizer. The visualizer is one of the most useful components in TestComplete when it comes to fixing and modifying your scripts. You can configure the Visualizer to take pictures when you record your tests, in which case you’ll see the images in the Key Word test workspace panel.
And you can see the comparison ‘Expected’ (from the recorded Keyword test case) and ‘Actual’ (from the test run) in the log files after you’ve run a test.
Typically it’s kept on whilst you develop your tests. And also kept on when running your tests for the first few times. You don’t want to keep it on for all your test runs as it’s pretty resource intensive. Once your test are running smoothly you would switch the visualizer off and enable just the ‘post image on error’ setting. This way TestComplete only takes a visualizer image when your tests pick up an error. Visualizer settings are found in the Project Properties tab (more on this later).
Next on our list of user interface components to look at is the Integrated Development Environment itself. There’s lots you can configure here. Just try dragging different components in the gui and re-arranging them. You can also close panels and open new panels (see above). What usually happens though is that you lose a panel or you just end up with a right mess. At which point you want to return everything to normal and reset. You can do this in the ‘View’ menu.
Up next is the Keyword test editor space then. This is where you’ll spend most of your time working. We’ll look at Keyword test development later but for now you just need to know about the main components in this panel. These are…
Test Steps: select this tab and you’ll see the panel where you have a list of all the test steps that make up the Keyword test. We also have the ‘Variables’ and ‘Parameters’ tabs but we’ll talk about those in a later module.
Operations: this panel gives you a list of test actions and other items that you can use in your keyword tests. For example there’s the ‘On Screen Action’ item that you’ll use countless times to complete actions within your application.
Visualizer: Images of the application as these test steps are completed (we’ve talked about this above).
Menu Bar Buttons: this is a panel with a range of buttons used to create and modify your Keyword tests. For example the ‘Append to Test’ button which allows you to start recording again and add more test steps to your Keyword test.
Whilst we’ve covered all the key components in TestComplete IDE there is one last, very important, bit to cover. This is a three step process you’ll use on a regular basis when inspecting, investigating and capturing the objects in your application.
This is VERY IMPORTANT. You may not understand exactly why yet (we’ll come to that as we start building tests) but get into the habit of following these steps. They should be 2nd nature to you before you move on.
Step 1. Open the object spy and identify the object you’re interested in. Or at least get close to the object you’re interested in (for example if it’s an Html table structure you might find it a bit tricky getting the exact object). Once you’ve identified the object click the “Hightlight Object in Object Tree”.
Step 2. At this point you should see the object tree with the object you’re interested in highlighted. Now you really get to see if you’ve picked the right object and you start to get a feel for the context of the object in relation to the rest of the objects in your application.
Now you can look in detail at the object, examine the other related objects and make sure you have the right one. When you have selected the correct object right click and select ‘Map Object’.
Now if you’re working with a particularly difficult application (e.g. the object are difficult to identify uniquely) then you can opt to ‘Choose a name and properties manually’ or you can just pick the first option and let TestComplete map the object. If in doubt pick the first option for now.
Step 3. The object browser is the list of everything on your system (all processes, windows, browsers, etc). When you map and object, and add it to the Name Map, you’re basically saying to TestComplete add this to the list of object that I’m interested in for my automation project. I don’t want a list of everything on my system, just a list of object I’m interested in for my project. That list is the Name Map.
And once you click the ‘Show Object in Name Map’ TestComplete will show you that object in this focused list of objects. This is the list we’ll build that will contain everything we need to know about our application for the purpose of our automation effort.
This might seem convoluted at this point in time. It may seem a little obscure as to why you want to repeat these steps. Just go with it for now though. Practice it a several times to get a feel for jumping between the Object Spy, Object Browser and Name Map. This interaction and movement between the Object Spy, Object Browser and Name Map is key to getting the most out of your automation with TestComplete. You’ll find out exactly why in the coming modules.