Java Framework Manually Defined
Search Knowledge Base by Keyword
This section covers our Java library which can be directly embedded into any framework coded in the Java language. To integrate data allocations with Java frameworks we expose a Java library which calls the API endpoints mentioned above. This is broken down into the two same functions as before to:
- Tag the data allocations against test cases to specify which allocations are required.
- Retrieve the allocation results to utilise them as values within a test.
The library and source code can be accessed at the following GitHub repository.
With TestNG you can tag each test with a ‘@DataAllocation’ annotation which is provided by the data allocate java library, shown below:
@DataAllocation(poolName = “pool”, suiteName = “suite”, groups = {“testname”})
Public void testDefinition()
Here you can specify the data allocation to connect the test with. This corresponds to three parameters:
- poolName – Name of the allocation pool the tests reside in.
- suiteName – Name of the test suite the test resides in.
- groups – The tests to perform allocation on. These are the allocation tests associated with the current test being tagged. Wildcards can be used to match multiple test names. The groups tag also takes a list so multiple test types can be specified.
These three parameters must match the data values specified for each matching test case specified within the appropriate allocation pool within the portal.
Within the test case you can retrieve the results using the ‘dataAllocationEngine.GetDataResult’ function. Here you can specify the pool, suite name, and test name to retrieve the results for. Again, this must match the specifications given in the associated allocation pool within the portal. The DataAllocationResult class shown below contains the functions to retrieve results by the column names, and column indexes as specified in the initial test criteria.
DataAllocationResult allocResult= dataAllocationEngine.GetDataResult(“pool”, “suite”, “test name”);
Before the tests are executed in TestNG we have defined a @BeforeSuite function which is executed before all the specified tests are executed. Within this function we collect all @DataAllocate functions tagged against any tests that are about to be executed, then we call the data allocation API to perform the associated executions.
It is more efficient to perform these operations in bulk. Which is why they are collected into one list and then sent for allocation as opposed to directly performing the allocation inside each individual script.
This implementation can be transposed to other testing frameworks (e.g. Nunit, Junit, etc) by replacing the appropriate keywords (@BeforeSuite, and @Test) with their corresponding values. The purpose of this java library is to provide a set of out-the-box methods for enabling you to call the data allocation API within your framework seamlessly.
-
-
-
- IEnumerable to Data Reader
- Data Table to List
- Nested String List to Data Table
- List to Data Table
- IEnumerable to List
- List to IEnumerable
- Remove from List
- Exists in List
- Value Exists in Dictionary
- Key Exists in Dictionary
- Remove from Dictionary
- Get from Dictionary
- Clear Dictionary
- Add to Dictionary
- Clear List
- Add to List
- Show all articles ( 1 ) Collapse Articles
-
-
-
-
- Explanation of Remaining Sheets in the Control Spreadsheet (for reference only)
- The ForeignKeys Sheet - Specifying which Foreign Keys to read from the Source Database
- The Tables Sheet: Defining Metadata that will be read from the Source Database
- The ProcessModel sheet – Toggling Subset Rules
- Refining the Control Spreadsheet
- Overview of the Advanced Control Spreadsheet
- Introduction
-
- Drop both Primary and Foreign Keys (The composite DROPKEYS Action)
- Validate Both Primary and Foreign Keys (The composite ValidateKeys Action)
- Add Both Primary and Foreign Keys (The Composite ADDKEYS action)
- Drop Tables
- Truncate Data
- Delete Orphans
- Drop Primary Keys
- Drop Foreign Keys
- Validate that Foreign Keys are Unique
- Validate that Primary Keys are Unique
- Add Foreign Keys
- Add Primary Keys
- Overview of Post-Subset Actions
-
-
- Use Event Hooks to call VIP Flows
- Different Methods for Connecting to Source Databases
- PreProcess Variables and Parameters
- Using SQL Functions to query Databases and Using the Queries in Data Generation Functions
- Summary of the Process to Configure the Test Data Configuration sheet
- How the PreProcessVariables Table is used in the Configuration sheet
- Sample Commerce Configuration Sheet Examples
- Adding Event Hooks in Configuration sheet for custom functionality
- How to Configure the Synthetic Test Data Configuration Control Sheet
-
-
-
-
-
- The UI Recorder
- Test Modeller – Maintenance
- Test Modeller Core (Linux) Optional – Postgres LDAP
- Test Modeller Core (Linux) Optional – SSL Certificate Installation
- Test Modeller Core (Linux) Optional – Active Directory
- Test Modeller Core (Linux) Installation
- Test Modeller: Software Pre-requisites
- Test Modeller : Installation components
- Test Modeller : System requirements (Windows, Linux)
-
-
-
-
-
-
- Common Problems
- Extend Test Modeller (Advanced)
- Edit Code Templates (Advanced)
- Import existing framework / custom page objects (Advanced)
- Execute Tests (Java)
- Generate Automation Code
- Build a Model (Java)
- Scan an Existing Web App
- Configuration (Java)
- Prerequisites (Selenium Java)
- Welcome Selenium (Java)
-
-
-
-
- Generate Optimised Test Cases and Data into Excel
- Implement Naming Conventions
- Page Object Generation
- Intelligent Page Objects
- Customising Page Objects
- Import Custom Code Snippets
- Rule-Based Test Generation
- Trigger Automation Execution from within Test Modeller
- Automation Configuration
- Test Data Automation for Gherkin Specifications
-
-