AngularJS will generate some HTML, you should take a look on Protractor instead asking for "no dynamic ids"
Agreeing on good element and attribute identifiers is essential with web applications.
Identifying elements is done by developers, designers and automation programmers.
In a traditional waterfall environment with most of the requirements and specifications placed up front you can agree that, for example, all elements that will be used, checked, clicked on, etc, have unique IDs.
Another option is to decide that all elements that are used by automation will have data attributes for automation. For example
<input class='smooth' data-primary-motion="1">,
<input id="l23" data-secondary-motion="2">, etc.
However, in today's predominantly Agile environment you have to take a more nuanced approach. You'll need to work closely with the other folks on the entire development team and agree on how best to identify elements for everyone.
When first working in such environments (in a QE automation role) I thought I could 'require' a unique id on every field or 'require' a
data-qa-... attribute/value on all fields for automation. I have since found that this ends up being a huge battle about naming elements and identifier that wastes a LOT of time and energy and is likely to start stupid naming battles that suck up good energy and generate bad energy. I've since learned to "live with what's there" for the most part and work within the existing framework. Some examples:
name=attributes for database related fields making them unique and removing the need to actually name them yourself as they just use the database column name field.
formmight not be unique as there are multiple forms on the page and none have
NAMEand you don't want to fight the battle and time it takes to add them. Upon examining the whole page, however, one might find that an identifier of
section.header formmight do the job.
table tr tr td td tdmight find a certain piece of data in a table but the table is dynamically generated and changes with data. In these cases use a different strategy such as using another identifier in the 'chain' or adding unique ids to data. This is also why you don't just right-click on the element and copy its xpath from a browser. You'll end up with a brittle path many times.
In addition to the issues of element selection on web pages you should also pay attention to:
Workflows. Be sure you understand the full path and screens used by happy, sad and options workflows. Happy is the minimal 'get everything right' path. Sad is making errors and seeing the feedback and then Options is doing as many 'additional' things as possible on either the happy or sad flows.
Devices and Browsers. Ask the developers (and the business folks) if they know which devices and browsers will be used / supported and which you should test in. They may need to think about this and research it. Also ask what they use if they test the UI at all. Look to avoid testing in a browser that developers don't check, and raising issues only to be told 'oh, we don't support that'. Make sure to base your browser usage statistics on YOUR traffic, not just stats from w3 schools etc. Make sure that if traffic is mostly mobile (increasing the case!) that developers aren't only looking at, say, Desktop Chrome when saying something works and is 'done'.
The Goldilocks approach. You don't want to over specify the elements, e.g.
body section table tr td div because you are now 'hard-coding' the structure of the web page which is very likely to change and 'break' your path. Similarly, you don't want to under-specify the elements. For example
form might work today with only 1 form on the page but tomorrow a 'sign-in' form might be added to the top of every page, and this new form might break your path (in this case by finding the first form instead of the 2nd, the one you wanted). In this case you should consider locators such as
section.heading div.feedback form (assuming those specific id and class names exist on your actual web page). Don't try to anticipate too much ahead though - that's not agile - so try to get it just right.
Existing tests. Ask the programmers to go over the (hopefully) existing unit and integration test to get a good sense of what are they testing. Ask them if they have any good ideas for bits of the UI that should be tested. Programmers have an inside view of the system and their different perspectives will often generate good test ideas.
Finally another reason to work within existing frameworks:
Some shops will absolutely refuse to allow you to add elements/attributes for automation to pages that end users use. Frequently the reason given is bandwidth. In reality, just given an image or two, the extra characters are usually less than 1% or even 0.1% of the total load, but despite this the directive is clear. One option here is to add a pre-processor that strips out these element/attributes for the live production site but leaves them there for test/staging for use by automation. I don't recommend this though as you are changing what the users gets from what you tested and it's not a good path to start down imho. At the end of the day this is why, although I've tried adding elements and special
data-qa-... attributes it's simplest, easiest and quickest to work with existing elements whenever possible.
Developers, designers, and automation engineers need to communicate and collaborate and come up with element/attribute identification methods that work for everyone.
I feel your pain - I have to deal with the same problem.
As any engineering task, you have restrictions, relations to other parts of the project, and trade-offs - so you deal with them in the most clever way you can.
Usually, developers add names/classes for me with little delay. If you need to locate something they don't work on, you can add names yourself and commit changes to the tree (following any review process your shop has).
Instead of automating after the code is done, try to automate during development together with the developers. This way you can solve any issues you run into together. Make it part of the definition of done of a feature.
So instead of planning ahead, try to fix issues as you run into them and get a common understanding of what is expected from each other. Else you might ask things from developers which you ain't gonna need.
Things I think that are important that need to be discussed are: