On Fri, Sep 9, 2011 at 4:58 PM, Leo Arias <email address hidden> wrote:
> In your first example, you are using the name as an identifier. It's not
> bad and it works, but it can be better. Instead of telling the website
> developers: "You should make sure that the combination of tag, text,
> class and name uniquely identifies your elements", you could tell them:
> "Set a unique id for the elements that should be tested".

...except that we'd then be adding quite a lot of markup to the page
that exists only for testing, and that also tempts css writers to use
those ids. I think it comes down to the fact that we're testing
something that does change, and occasionally tests will break because
the app has changed (that's a good thing), it's just deciding on a
balance of how often you get false positives - I think there are pros
and cons both ways. My rule of thumb is to use meaningful/semantic CSS
selectors for functional tests - using the existing markup - where
possible.

> So, having two elements with the same name is not a
> bug, and there are lots of cases where having the same text and class is
> required.

Sure there are cases like that - and in those cases I'd add an id if I
can't make a non-fragile test without it. It's just the idea that
"adding ids to elements should be a development rule" that's strange
for me... but as said, it's not my project, I was just interested in
the discussion :)

> In your second example, you add the text, but that doesn't
> always work,

That is true - it doesn't always work, but it wasn't an example to
show a rule that always works... Maybe that's what you're after, in
which case I'd say, yes the only way to do so is to add an id - that
will enable you to access all elements in the same way (via a unique
id). I'd not recommend doing that myself, but that's not relevant here
:)

> and you can see the Services page example I mentioned. This
> page has no visible UI issues, it makes perfect sense to have the same
> text on both buttons. The bug there is not the lack of a unique
> name/text/class/... combination, it's the lack of an id.

That may be the case for that example - but I still don't want to add
ids to every element just because there are situations where I need
ids.

>
> We always have a workaround making xpath expressions as complex as
> required,

I think css selectors are much easier to read, if they're available to you.

> I think that source code must be
> written with testability in mind, and that by trying to make the tests
> for your code as easy as possible, your code will be of a higher
> quality.

I agree but don't think that means adding ids to every element. Adding
an id where one is required because the test is too fragile or unclear
- great - adding an id to every element required for testing... hrm,
that's where I'm not convinced (yet) :) That said, I'm not a QA person
- so I might just be thinking like a dev - perhaps it's obvious to
anyone who's written lots of functional tests...

> As a result, your tests will also be of a higher quality. But
> we can make some compromises here, like setting the importance of this
> bugs to medium :D

heh :)

> Oh, I forgot. I don't have access to your branch. Please let me read it.
> We'll need to find some way to use your tests instead of rewrite them.

Done! Enjoy.