Ten Development Tips For Testable Websites


(See also the post on Ten Tips for Testing Web Applications, aimed at Testers)

Developing web applications can be optimised to make the Test cycle quicker and more thorough. The HTML mark up – if written with automation in mind – will make automated test vastly easier to write and maintain, allowing builds to be more robust and code to be released more frequently with a higher quality. Furthermore, adopting a defensive approach to data validation and processing will lead to much more secure applications.

These tip have been divided into the following categories:

  • Data Validation
  • Optimising for Automation
  • Other

1. Validation: Validate all input fields

All input fields need to be validated even if only being stored in the database. Can XML, SQL or other code be entered? What is the implications of this happening (various injection attacks, usually, such as SQL Injection, XSS, etc.)? Also remember that the data may later be used in ways it was not originally intended, for example reports, logs, etc.

2. Validation: Check all input fields are validated on the server

This sounds the same as point 1 but it’s not. With the ever increasing use of JavaScript libraries it is easy to forget that client side validation is only for the users’ convenience, not for security.

3. Validation: Escape all user supplied data

When anything is displayed to the user, you need to think about where the data has come from. Has it been imported from another site? Is it supplied by a user? Is there even a small possibility that this data is going to be not what is expected? Write defensive code that can cope with malicious or erroneous input.

4. Automation: All clickable elements in the page need an ID or Name

When trying to select a button in an automated test it is easiest to do this when it has a unique ID. This means the QA engineer doesn’t have to write complex XPath or even regular expressions to select the button required which then may not work if the component is moved to a different location.

5. Automation: All elements that are part of a test need an ID or Name

Providing a div with a name, class or ID will make it very straight forward to check for in code. It will not be reliant on the content that could change or mean that the test has to be re-written for internationalization.

6. Automation: All values associated with data selection need to be hyperlinked

For example, if displaying a table of data with checkbox selections to access the data behind, then an automated test will need to select the individual item before being able to access the data. If the table row had an ID or name these both would be easily selectable using XPath.

7. Automation: Don’t use JavaScript alert()

The classic JavaScript alert() function, once the mainstay of web-page testing, are a bane for testers. Not only do these give the site an outdated feel, they also do not have good support with automation tool such as Selenium. This can make it difficult to confirm when an event has fired and leads to reduced coverage of automated test and load tests

8. Automation: Only use frames where absolutely necessary

Issues arise when using  automated testing tools with frames, because frames are loaded a synchronously and behave differently in different browsers. Furthermore, selecting a object often fails when it is located in a different frame causing writing tests to be more cumbersome and the tests to be less stable.

9. Other: Develop using multiple browsers

Testing in every browser would be close to impossible. However at least Firefox, Chrome and Internet Explorer should be used by the developer, and different versions of IE should be checked regularly along with Chrome and Safari. Note: although Chrome and Safari use the same rendering engine ( WebKit ) they use different implementations of JavaScript so both need to be checked.

10. Other: Make components easily “mockable” for Unit Tests

This will make it easier when isolating areas of erroneous code and allow unit tests to be written in less time; for example, the ability to pass configuration to the constructor instead of auto-loading from a configuration file makes testing components substantially easier.

Leave a Comment

(required)