Best practices for developers to increase testability of web apps for QA?

Question

I'm writing a document for a developer at my company who will be working on a web app. Here's the advice I have for him so far (below). Can any of you think of more that I can add? Not sure which tool we'll be using, but Selenium and WatiN are strong contenders.

1. Where there are AJAX-heavy pages, especially when they have a big range of times to finish loading, help QA with hidden elements or JavaScript variables to indicate when the relevant AJAX piece (e.g. a data table is done loading)
2. Web elements should be:
   • a. Uniquely identifiable - Selenium prefers id (fastest for looking up elements)
   • b. Ideally, human-friendly, e.g. firstName instead of input82347
3. Favor standard web elements like <input> over many layers of nested <div> for the UI
4. Class names and other element attributes should not be repeated unless it makes sense, e.g. don't use the same class name for functionally different components (cheesy example: both <tr> and <td> having the exact same class name)
5. Selenium doesn't like compound class names (e.g. classname="classPart1 classpart2")

Answer 1

1 may be necessary, but it's also possible to handle it by executing some javascript. For example, if the ajax page is using the jquery library, you can do this:

bool isAjaxFinished = ((IJavaScriptExecutor)webDriver).ExecuteScript("return jQuery.active == 0")

4 and 5 on your list don't seem necessary and may actually be counter-productive. Selenium does fine with compound class names, and it would actually be extremely difficult in terms of CSS/presentation to restrict it that way. If the classname is not unique and maybe even if it is, give it an ID (which is the fastest way for an element to be found via selenium).

Another thing that I run into a lot would be dynamically generated elements, usually in a list (like messages in an e-mail inbox, or list of saved something). Working with them may be difficult since there can be varying numbers of them, with varying text. The easiest way to work with these elements is generally to give the parent element a unique identifier and then get a list of all of the child elements using xpath.

Answer 2

Overall best practices for testability is difficult, since that could involve whether the code "hides" defects (e.g. race conditions causing intermittent threading issues or difficult corner case issues). Usually testability goes hand in hand with good development practices: well documented code, following a coherent coding style standard, and good communication practices. Once you clear away the "distraction" defects due to inconsistent development practices, it is much easier for the team to address the more severe defects.

If there was any one item that I would identify as an overall best practice, it would be to pay attention to accessibility. You touched on that in #2, but it goes farther than just providing unique screen object identifiers. Developing a well-organized web page structure that allows interaction with external text readers makes the app naturally compatible with GUI-based automation like Selenium and makes overall testing of the app much easier.

Answer 3

Just a comment, no matter how many documents are written for developers about producing testable code, the code will still not be testable, until developer tries to write some automation for his code. IMHO, spending half a day when dev sits side by side with a person who knows how to use one of the UI automation frameworks and trying to write some automation code can provide more value than any number of written documents/guidelines/etc.