How Element Explorer and Element Repository works in Telerik Test Studio

In TTS Element Explorer and Element Repository plays vital roles. In this blog, I will explain how these work in TTS.

What is Element Repository?
Element Repository is an in-memory collection of all elements. This repository as single is not persisted on disk. It relies on the individual element definitions that are persisted with each test.

 What is Element Explorer?
Element explorer is similar to Dom Explorer. In short it contains the elements that are required to run your test. When a Test Project is loaded all the elements from all the tests are merged into Element Repository, which then gets displayed into Element Explorer.
 

On what basis elements get added to Element Explorer?
In TTS Project settings, we have an option called Compare Mode in 'Recording Options' section. Based on this setting only the elements will be added .Compare Mode can be checked against the page's Title or one of multiple settings that look at various parts of a URL. Choose corresponding Compare Mode with respect to your need basis.

When elements gets added to Element Explorer?
There are two ways from where we can add elements
1. While Recording steps  - Whenever we record a step, elements will get added to the element explorer automatically.
2. Manually Adding desired element using TTS Recorder - From the recorder choose an element in the Dom and select 'Add to Elements Repository'.


How the Elements are Organized in Element Explorer?
For HTML Tree view -> First it adds the page then Frame, then the Test Region and Element.
If we do not have any frame or region, then the element will be added directly to the page node. In the below example we do not have Frame and Region so elements are added directly to Page Node.

How elements are bind to test?
Each test file keeps a definition of all the elements that particular test uses. Each recorded step maintains 'Friendly Name' and Find Expression that is used to identify the element on the web page during execution. So whenever we are deleting a particular test, its corresponding elements will also gets deleted from Element Explorer.


How elements in coded steps work?
When we convert record step into a coded step, the element definitions are changed into 'External Reference'. This means that elements still binds to the test but they are not tied to specific test step. The same will be happen when we add elements by selecting element from Dom Explorer using 'Add to Element Repository'. There is a file called Pages.cs which is a hidden file and is automatically generated by Test Studio. This file is only used by coded steps.Test Studio generates this file from the elements contained in the element repository, which are displayed in the Elements Explorer.

When Pages.cs file will be generated?
Pages.cs file will be automatically generated by TTS in below cases.

• When the test project is loaded by Test Studio.
• When you add elements, such as when you record new test steps.
• When you delete elements, such as when you delete a test step or an entire test.
• When the test project is built on your local development box or on a build server.

How is the Element Repository used during test execution?

During test execution, the root Page node is not actually used to locate the element. The execution engine only uses the Frame, and the element's Find Expression to locate the correct element to interact with during any test step. This allows the test to continue to work when you need to test in a different testing environment (e.g. a Development server, then a Staging server, then a Production server).

Passing variables between tests in TTS

In all the automation suites general requirements is passing data from one method/test to another method/test.

In TTS you can achieve this behavior in three ways

1. In Telerik Test Studio, for each Telerik test we have an option called 'InheritParentDataSource' property. Once we set this property child test calling can access this variable.

 2. Using Extracted Variables - These are stored in a global data dictionary and exist for the entire life of the test. Both child tests and parent tests have access to these variables.

You can achieve this in two ways

•   Using Recording steps.

1.      Start recorder and enable 'Highlight Element'

2.      Select the desired element, choose Quick Steps > Extract - text contains entry. This adds the Extracted step to the test. In the test drill down the extracted step and set desired DataBindVariableName. (Step 1)

3.      Record the step where you want to use this extracted variable.

4.      In the test, select the step where you want to set the text. (Step 2)

5.      In the properties pane click the 'Bindings' drop down. and select the extracted variable from the value drop down list (Step 3) 

6.   Click Set.

   

• Using Coded Step

 In the telerik test add Script Step and use below variables for setting and getting values via code. 

  Example :
    string name = "Test Automation";
    SetExtractedValue("extractedID", name);
    Object nameVal = GetExtractedValue("extractedID");

   
3. Writing your own custom code. ex: Create a global variable in code which can be accessed anywhere in the code.

Telerik Test Studio Limitations

S.No	Description	Category	Solution
1.	Element highlighting will not work.	Development	Set the browser zoom level and system display level to 100% always.
2.	Firefox browser should be configure to open URL in new windows	Development	No solution
3.	Renaming/deleting the elements in Element Explorer will not change in code automatically.	Development	Do not rename/delete the elements used in coded steps.
4.	When recording is started, the elements added will be directly associated to the active test. So, deleting this test will delete all the added elements of the current test.	Development	Open the corresponding test and add the elements or record the steps directly to the active test which are related to current functionality.
5.	When a TTS project is created in Visual Studio and opened in TTS standalone version, the external references will not be available for the tests during runtime	Runtime	Copy the ‘packages’ folder which has the external references and place it inside the project folder where .csproj file exists i.e., inside the TTS project folder.
6.	When test lists are scheduled and changes are made to the same test list later, the latest project files will not be automatically uploaded to storage DB	Runtime	Manually right click on the scheduled test list in the timeline of ‘Results’ section and click on ‘Upload latest project files’ option.
7.	Usage of mouse and keyboard events in the test	Runtime	Works only when the mouse and keyboard focus on the executing browser.  If you are using VM always the screen should be active. If you distribute the tests in different VMs we need those many physical machines.
8.	Launching browsers with custom options	Development	Cannot open browsers in private mode Cannot create our own profiles

Business Continuity/Zero Downtime Testing in Blue Green deployment

As per wiki definition,

“Business continuity encompasses a loosely defined set of planning, preparatory and related activities which are intended to ensure that an organization’s critical business functions will either continue to operate despite serious incidents or disasters that might otherwise have interrupted them, or will be recovered to an operational state within a reasonably short period.”

During deployment

·         Our business should continue with existing production environment and customers should be able to operate and work with our products without any interruption

Once deployment is completed

·         Customer should be able to see the changes in the build and able to operate with our products seamlessly

Business continuity also means that customers should able to operate with our products in case of deployment failures. We should identify the time taken for disaster recovery during hot upgrade deployment in case of deployment failures.

Business continuity can’t be simulated with manual testing alone. In Production, we are not sure how many customers are using our products, what the load on production is and what the customer user cases are. We can automate Business continuity tests by continuously running the tests before and during upgrade deployment. We should make sure that none of the automated tests should fail during upgrade deployment because of deployment issues. We are calling this as Business Continuity/zero downtime testing.