Project Glossary

User roles

Current table is aimed to describe the main user groups

#	User group	Definition

#	User group	Definition
1	Customer	User
2	Developer	A person who has direct access to the database and all sources

Glossary

#	Term/Acronym	Definition

#	Term/Acronym	Definition
1	JDI	“Just Do IT” JDI is a Community for modern tools for Test Automation with Open code (https://github.com/jdi-testing )
2	JDN	“Just Do Nothing” JDN is a Google Chrome plugin for UI test automation (https://github.com/jdi-testing/jdn )
3	ROBULA+	Robula+ is an algorithm to generate robust XPath-based locators, that are likely to work correctly with new releases of a web application (https://github.com/cyluxx/robula-plus ).
4	Page Object	Page Object - simply speaking, is a Java class (if we are talking about the java stack) that contains methods for working with a specific page of a web application. The method can implement both a simple action - for example, clicking a button, and the implementation of business logic - for example, logging in with a specific user and password. In JDN, automatic implementation of business logic is highly unlikely, but actions with controls are quite possible. Example of a page object in a Java stack using JDI Light: `public class ContactFormPage extends WebPage { @FindBy(xpath = "//[@index='5']//[@index='2']/a") public Button okButton; }`
5	Frameworks (JDI Light, Vividus, Selenium, Selenide)	Automation frameworks are libraries that provide APIs for working with elements on a web page. The first such library to become an industry standard is Selenium. All other libraries for the most part use Selenium as a basis, extending its capabilities, but they do it in different ways (that’s why there are so many of them). Let's say - JDI Light provides an API for working with typed elements (while the rest consider elements as simply a universal WebElement for which all possible methods are provided and only the TA engineer must decide which of them are applicable and which are not). The advantages of VIVIDUS include the default implementation of the BDD approach to writing tests, which, as planned by the developers, can allow even non-automation specialists to write tests.
6	Libraries (HTML5, Material UI, Vuetify)	Element libraries. Now on the market there are many frameworks for front-end development. Although 95% of the market is covered by five - HTML5, Angular, React, Bootstrap and Vue.js. Each of these development frameworks implements one or more element libraries (usually from 30 to 70 elements per each). JDN will support the most popular ones, say for React - this is Material UI, for Vue.js - this is Vuetify. The choice of supported element libraries depends on JDI Light - which ones it supports - those supported by JDN. There is no point in supporting others.
7	Annotations (UI, FindBy)	You can read what annotations are here: But in short, these are tags in the code that allow you to enrich entities in the code with different properties and capabilities. JND uses JDI Light annotations (which also uses Selenium annotations) to enrich the element that we are going to declare in the code - with locator, using which you can find it on the page. For example: `@FindBy(xpath = "//[@index='5']//[@index='2']/a") public Label mobileAndHtml5;` In this code, we declare an element of the Label type (essentially, we create an object) with the name mobileAndHtml5, which can be found on the page using the locator //[@index='5']//[@index='2']/a. And its locator type is xPath. The use of annotations is optional. Some frameworks, such as VIVIDUS, do not support annotations, so declaring elements there looks like this: `variables.MetalAndColorsPage.Label.mobileAndHtml5=By.xPath(//[@index='5']//[@index='2']/a)`
8	Locator types (CSS, xPath)	Locators - simply speaking - are a text string that allows you to find an element on a page (depending on the type, the string is interpreted differently). You can read about them here: In total, there are 8 different types of locators that can be divided into 3 groups. Locators that bind to DOM attributes of an element - for example - id, name class name, and so on. Their presence in elements is not guaranteed, so their use is not always possible. The other two groups contain one type each - xPath and CSS Selector xPath is the language used to query the XML document. The same can uniquely identify the web element on any page. The most versatile type. CSS Selector is used to create style rules for webpages and can be used to identify any web element. like xPath - it is always present in the element, but not so convenient and universal in properties
	Project template	Project template is a test project for test automation that combines all the necessary libraries for writing autotests. The set of these libraries depends on the choice the user makes when creating the first page object in JDN. Simply speaking, each automation framework - JDI Light, VIVIDUS and others - have its own project template.
9	[Element] Visibility	Visibility - not all elements that are on the page are visible (isDisplayed) to the user. Different element properties can affect this. On the Internet, as well as in the Selenium code, you can find the following rules: css property display: none DOMRect: width/height === 0 css property opacity: 0 css property visibility: hidden html attribute "hidden" css property visibility: collapse OVERLAPPED by another element Hidden parent element However, whether an element is visible to the user (isDisplayed) is decided SUDDENLY by the browser itself. Different browsers decide differently, for example this element: in Chrome it will have a size of 0x0, and in Firefox it will be 8x2, so even if, for example, rule number 2 worked, cross-browser compatibility is still not achieved due to differences in the browsers themselves. Therefore, to determine the visibility of an element, we ask Selenium, which in turn asks the browser through the web driver. This is honestly written in the standard - In short, it says: "WebDriver does not define a primitive to ascertain the visibility of an element" Here we include a recommended approach which will give a simplified approximation of an element’s visibility this "recommended way" is exactly the bot.dom.isShown function, but browser and driver manufacturers are free to make their own implementation. therefore, you cannot rely on the bot.dom.isShown function with confidence, you need to look at the driver code
10	xPath	XML path used for navigation through the HTML structure of the page(https://www.guru99.com/xpath-selenium.html#1 ). XPath is a language for traversing the structure of the DOM (document object model) of the web page. XPath locators are very powerful and flexible. Any element on the page can be located via one or more XPaths and most other locators can be expressed as an XPath. Excepting CSS Selectors, no other locators share this feature. A well-written XPath can be very robust, but a poor XPath can be fragile – meaning that it may break when the application changes ( ). Simulator:
11	Material UI React	Library of React components, based on Google Material Design.
12	Angular Material	Library, based on Google Material Design.
13	Bootstrap 4.3
14	HTML5
15	DOM	DOM defines a platform-neutral model for events, aborting activities, and node trees ( ).
16	CSS	Cascading style sheets are used to format the layout of Web pages ( ).
17	Locator	An element locator, usually referred to as simply a locator, is a method for finding an element on a page ( ).
18	Web Page	Documents are written in HTML (hypertext markup language) and are translated by your Web browser. JDN creates Page Objects for Web Pages

19	CSS selector	CSS Selectors are similar XPaths – they are flexible and powerful. Unlike XPath, they are not based on the structure of the DOM and don’t navigate the DOM in that manner. However, they can do some things easily that is somewhat hard to do with XPath. If your application uses a lot of CSS, then your developers are likely very familiar with the concept and can help you devise CSS Selectors to find any element on the page ( ).