# Please add ids to perspective components for writing tests **URL:** \ **Category:** Ignition\ **Created:** [May 20, 2021, 5:54pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949 "2021-05-20T17:54:53Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tony.petruzzi1](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@tony.petruzzi1](https://forum.inductiveautomation.com/u/tony.petruzzi1)\ **Post date:** [May 20, 2021, 5:54pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/1 "2021-05-20T17:54:53Z")
I don’t know why this was overlooked during the design of Perspective 🤨 , but this is caused major heartaches when trying to write tests. Currently there is no way to add an id to a component in Perspective and when trying to write tests using Selenium IDE is just fails miserably. I come from the web world and it has been instilled in me to always give an id to elements so you can easily reference them during tests. Nothing I’ve tried allows me to add an id to the component so that I can reference them, I’ve even tried creating an id in the props which did nothing ☹ What testing framework are others using with success? ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [May 20, 2021, 6:46pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/2 "2021-05-20T18:46:40Z")
This feature has existed since the initial release of Perspective but hasn’t been widely publicized. In newer versions of 8.1 it is a little bit easier to find. Within the META area of a component property editor, adding a `domId` Property with a value of the ID you want to add will allow you to set whatever ID you wish. ![domId](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/b/ab36a4a48c236308486c0ebd7122a58682af18c4.png) Garth ---
**Author:** ![tony.petruzzi1](https://avatars.discourse-cdn.com/v4/letter/t/3d9bf3/32.png) [@tony.petruzzi1](https://forum.inductiveautomation.com/u/tony.petruzzi1)\ **Post date:** [May 20, 2021, 8:03pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/3 "2021-05-20T20:03:13Z")
Thank you very much for the information. I really wish they would make something like that a little easier to find and also add ids automatically to components that we could then just overwrite. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [August 18, 2021, 7:00pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/4 "2021-08-18T19:00:20Z")
@Paul.Scott can this be added to the documentation? This is a huge item for integrators that is not really called out anywhere. This is essentially the first step in any UI testing for perspective, and its not very readily available ---
**Author:** ![Paul.Scott](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul.scott/32/4578_2.png) [@Paul.Scott](https://forum.inductiveautomation.com/u/Paul.Scott)\ **Post date:** [August 18, 2021, 7:17pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/5 "2021-08-18T19:17:42Z")
Certainly, but it looks like we already added `domId` to the manual back in May: [Meta Properties](https://docs.inductiveautomation.com/pages/viewpage.action?pageId=58595292#PerspectiveComponentProperties-MetaProperties) ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [August 18, 2021, 7:50pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/6 "2021-08-18T19:50:48Z")
Ahh! I was searching in 8.0 documentation, not 8.1! Thanks Paul! ---
**Author:** ![Paul.Scott](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul.scott/32/4578_2.png) [@Paul.Scott](https://forum.inductiveautomation.com/u/Paul.Scott)\ **Post date:** [August 18, 2021, 8:44pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/7 "2021-08-18T20:44:35Z")
That’s a good point. I have no idea if `domId` already existed in 8.0. I’ll figure it out, and update the 8.0 docs if that’s the case. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [August 19, 2021, 2:18am UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/8 "2021-08-19T02:18:34Z")
I can verify the’ve existed since Alpha 8.0. ---
**Author:** ![michael2](https://avatars.discourse-cdn.com/v4/letter/m/3e96dc/32.png) [@michael2](https://forum.inductiveautomation.com/u/michael2)\ **Post date:** [August 19, 2021, 3:14am UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/9 "2021-08-19T03:14:05Z")
@kgamble Can you please provide some examples or point me to some resources of how this assists with UI testing? I’m in a position where I regularly have to verify that connections to tags are correct and would like to find some better methods. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [August 19, 2021, 3:45am UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/10 "2021-08-19T03:45:26Z")
By setting the `domId` property of a component, you’re able to interact with the component via automated testing by targeting the supplied id, versus targeting via either CSS selectors or XPATH. For example, we use Selenium/WebDriver for our internal testing and by supplying domIds to important elements, we can use something like this: ```auto self.driver.find_element(*(By.ID, 'my_dropdown')).click() ``` as opposed to something like this… ```auto # this uses indexing, which is fragile self.driver.find_elements(*(By.CSS_SELECTOR, 'button.button-primary'))[0].click() # and XPATH is more precise, but is even more fragile in most instances self.driver.find_element(*(By.XPATH, '//*[@id="app-container"]/div/div[2]/div/div[2]/button')) ``` ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [August 20, 2021, 6:19pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/11 "2021-08-20T18:19:17Z")
Exactly what I would have said! Except here is a slightly more filled out example in python with chrome web driver ```auto import time from selenium import webdriver driver = webdriver.Chrome() driver.get('http://localhost/data/perspective/client/Test') time.sleep(2) button = driver.find_element_by_id("myExampleButton") button.click() driver.quit() ``` ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [August 20, 2021, 6:22pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/12 "2021-08-20T18:22:29Z")
Separate question though, is it possible to get any of the react state props from the component once a reference is achieved? I know in some cases (like a button) you can get certain values like “Text” because you render it to the DOM. However for custom properties that we create, is it possible for us to access those? Or would it be a feature request to ask for an access control type for properties that puts it in the Dom for testing? Example case: 1. I use selenium to UI test a screen and verify that when I click a button that it updates a custom property of something else 2. To update the property I click on the button with selenium 3. To verify the property changed, I get access to the other component and look for the custom property that we updated. I tried doing things like setting access settings, and digging around through the button object through debugging, but I was unable to find anything. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [August 20, 2021, 7:08pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/13 "2021-08-20T19:08:53Z")
it’s going to require you to run browser-side JS: ```auto driver.execute_script("return __client.page.pageProps.root.value.value._data") ``` And the script involved is going to be 100% index based. So… I really advise against this. Notice that `root` is an attribute of the page? So you can drill down through component hierarchy, but the moment you change the hierarchical structure of the View your script will fall apart. This also only works for viewing properties which have “Public” or “Protected” access. And as far as custom properties go they are not exposed in the DOM because they are just server-side data and don’t directly pertain to appearance or data. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [August 20, 2021, 7:15pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/14 "2021-08-20T19:15:06Z")
I see what you are saying, does seem a little sketchy. > [@cmallonee](#): > > And as far as custom properties go they are not exposed in the DOM because they are just server-side data and don’t directly pertain to appearance or data. In regards to this, if it does directly pertain to the data relevant on screen, would it be a valid feature request to allow the ability to expose certain custom props to the Dom for testing? For example if I am running a test to verify that a page is pulling in 10 rows of data and they all have the right values, currently I can only do that by iterating through the rows and looking at the text in each cell by order Long term that feels fairly in-scalable incase you guys happened to change the names of any of the classes, the we hide a column, or if they are reordered, we now may not be able to see the data we are checking against? It would allow for full end to end testing as opposed to just making sure a button is showing up and can be clicked Is there a better way to test this sort of scenario? Or a reason why we would not want to do this? Or if it is just genuinely not possible for you guys to allow this level of property exposure to the Dom ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [August 20, 2021, 7:29pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/15 "2021-08-20T19:29:36Z")
The problem is you're using a front-end testing tool to test back-end data. It's extremely unlikely we would add other properties to the DOM because of the limited usefulness compared to the performance risk of exposing potentially MANY more properties (you might have one or two properties on your button, but UserX has two dozen Datasets polling regularly). On top of that, we'd have to expect work around security settings applied to those properties so that we only inject properties set to be public or protected. > [@kgamble](#): > > For example if I am running a test to verify that a page is pulling in 10 rows of data and they all have the right values, currently I can only do that by iterating through the rows and looking at the text in each cell by order How would you test Datasets? > [@kgamble](#): > > Long term that feels fairly in-scalable incase you guys happened to change the names of any of the classes, the we hide a column, or if they are reordered, we now may not be able to see the data we are checking against? This is something I'd brought up internally in the past. I feel like there's a small subset of users who would appreciate access to our automation repo or even a way to bundle it with the release either as part of the Perspective Module or as a separate Module. The reason we haven't done this so far is it would require us to essentially dedicate resources to maintaining and updating _another module_ for a subset of users. This costs us time, money, and manpower and would be one more thing we would need to run through quality processes each release. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 20, 2021, 7:47pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/16 "2021-08-20T19:47:07Z")
Actually, Cody’s script above can be adapted to be a bit less fragile without too much trouble. ```auto client = __client mounts = __client.mounts mainViewId = `${mounts.center.viewPath}@${mounts.center.code}` mainView = client.page.views.get(mainViewId) mainView.custom.read("key") // or readArray, readDataset, etc ``` Still somewhat fragile, but not _as_ bad. `PropertyTree` on the frontend has various methods to read values from the model as different types. Custom properties _are_ currently ‘synced’ to the frontend, though as Cody mentioned, that default may be changed in the future, since outside of automated testing there’s little point in synchronizing custom properties to the frontend. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [August 20, 2021, 8:52pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/17 "2021-08-20T20:52:42Z")
In regards to the example, I see that you got the `mainViewId` but how would you do this for other items than the view itself? Would it be possible to use similar syntax to grab specific components? In the example of just dropping a button on a page, how would one generate the id of that button for reference? Or would you be limited to only accessing custom props on the main view? I see where digging through the component children I do eventually find it, just not sure if there is a cleaner way that I am unaware of. > [@paul-griffith](#): > > that default may be changed in the future, since outside of automated testing there’s little point in synchronizing custom properties to the frontend. Definitely if this is moved, it would at least be a nice optional property to change from default, to allow for this style of testing down the road. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 20, 2021, 9:01pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/18 "2021-08-20T21:01:32Z")
You could continue to drill down into the view (it has a `.root` property, which is the base of a tree of component instances. You will have to drill though that tree by index, essentially; you could write helper functions that search that tree for paths, but I don’t see any convenient utils exposed on the frontend. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [March 21, 2022, 8:59pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/19 "2022-03-21T20:59:44Z")
> [@cmallonee](#): > > The problem is you’re using a front-end testing tool to test back-end data I was reviewing this old topic, as I am in the same scenario where I am trying to validate some data that gets provided to the front end in tests. I hit this comment and was curious, what type of tool would even be able to test this type of backend data out of Ignition? For example, if I have a perspective screen that is running a function to return a list of objects, and lets say that each of those objects needs to read a tag value (something Ignition specific is really the point there). How would you recommend automatically testing that? If it was pure python, I can just make sure its compatible outside of jython and write pytests for it, which we have done, but in the case that we need to evaluate with built in Ignition (or say Sepasoft) functionality. Aside from writing a module, the only thing I can think of is essentially rebuilding pytest to work in Ignition without the premise of ` __file__ ` since you can't grab that most of the time (if at all, if I remember correctly) The cleanest thing I can think of, is building simplified perspective screens that act as a unit test for functionality, but then we need to rely on the ability to serialize that data into something visualized, or accessing component props. > [@paul-griffith](#): > > ```auto > client = __client > mounts = __client.mounts > mainViewId = `${mounts.center.viewPath}@${mounts.center.code}` > mainView = client.page.views.get(mainViewId) > mainView.custom.read("key") // or readArray, readDataset, etc > > ``` Which per this comment, I actually did add some logic to a Perspective focused selenium test library, but it is not fully fleshed out, and I am not sure if its the right answer long term. EDIT: As a general note, the ability to integrate typical devops practices in Ignition are definitely headed in the write direction (i.e. changing .bin files into text based files) . I look forward to stuff like this being more trivial than needed to write fully customized libraries and modules just to handle CI/CD ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 21, 2022, 10:08pm UTC](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949/20 "2022-03-21T22:08:41Z")
The way we actually test that is... by "dogfooding" Perspective. From your example: > [@kgamble](#): > > I have a perspective screen that is running a function to return a list of objects, and lets say that each of those objects needs to read a tag value We would either bind labels against the list of tag values or use messaging to write to Labels, and then verify the labels have the expected values (after first-off checking the labels do NOT have the expected values). In many ways we do use a front-end testing tool to verify at least some back-end functionality. [Next page](https://forum.inductiveautomation.com/t/please-add-ids-to-perspective-components-for-writing-tests/46949.md?page=2)