Testing

Digg This!

Page 1 of 2   next page »

When organizations focus on exposing errors in any kind of application, they traditionally focus on testing. Once an application is finished, it's passed to a QA team to find and report problems. There's some back and forth as the QA team reports problems, development fixes them, QA retests the application, and so on. Once that cycle has been repeated a few times (if there's time for that), the application is released. This approach is problematic, however. The quality of the application is assessed at the end of the project. By that time, incorrectly implemented requirements or bugs may be firmly planted in the application and have features built on top of them, and addressing the problems can be very difficult and time-consuming, if not impossible. With no way to determine whether the quality objectives are actually being met throughout the development process, it's impossible to deliver a truly quality application.

Another issue unique to Web applications that deliver critical business needs is that many of them are in a continual "beta"state. There's no time for a traditional development cycle where requirements are defined and the application is then architected, built, tested, and released. Features are put into the application as quickly as possible because they affect the bottom line. Since there's no time for heavily investing in the design of a new feature, it's quickly added as a "trial"; if the feature doesn't meet the needs of the customer, it can be removed just as quickly. This means that many Web applications are in a continual state of flux; there's never a finishing point. Features are simply added one or two at a time, on demand, as they're needed. Without being able to take any significant amount of time for testing, how do you ensure the quality of the application?

The answer to ensuring quality lies in creating a quality infrastructure that enables an organization to establish quality through all stages of development. However, in the case of AJAX applications, the following challenges arise:

1.  AJAX applications are very complex. A large number of components make up the application such as application server, database server, back-end Web Services, client-side JavaScript engine, and different browsers with different JavaScript/DOM implementations, just to name a few. Logic no longer resides only on the server, but also in client-side JavaScript. Figure 1 shows the aspects of a typical AJAX application on which I focus in this article.
2.  The user interface is put together bit by bit - it consists of an initial HTML layout, followed by inserted data from asynchronous server requests, all constructed using a JavaScript engine to produce the finished result.
3.  Because Web applications are delivered through browsers, and browsers have different JavaScript/DOM implementations, it's crucial to test the Web application against different browser types and versions. This can be time-consuming and tedious if it's not automated.

Because of these complexities, AJAX applications require specific ways of ensuring their quality. In this article, I'll focus on what it means to define a quality infrastructure, and I'll also explain what that looks like in detail for an AJAX application.

Defining and Enforcing Development Best Practices
The first step in building a quality infrastructure is defining quality at the beginning - with developers. This means defining the development best practices that are going to be followed to ensure that when the application is ready for deployment, it has been developed correctly the entire time. You may not think that this is important, but consider this: the quality of the code base for your Web applications directly influences your organization's bottom line. If the application works properly, more customers use your services; if it doesn't, they may never return. Functional and other kinds of tests are crucial to validating the quality of your application; however, testing finds errors after they've been introduced. Many errors can be prevented simply by identifying them in your source code as soon as they've been added.

One source of best practices that you should adopt is common industry best practices for how code should be written to prevent errors. Conventional wisdom exists regarding the best way to write code in different languages to solve different problems. Any given project may not benefit from all the coding best practices that exist, but every project can benefit from some subset of them.

In addition, your organization may have defined its own internal standards for ensuring that applications are written properly. Most development groups already have these kinds of best practices defined, either formally or informally. However, defining them is only part of the solution - you must also enforce these best practices.

Best practices do no good unless they're followed. You'll get pushback from developers here. I know because I am one. Developers don't like being told how to write code. However, if the infrastructure is defined in such a way that best practices can be enforced and followed painlessly, developers can easily adapt. Enforcing best practices means using some means (either open source or from a vendor) of validating the code on a regular basis to ensure that best practices are being followed. Each developer should be able to run best practices validation on his code before checking it in. There should also be a nightly process running against the entire code base that identifies violations and which developer is responsible for them, and sends a report to that person so that he can fix them. This handles cases where the developer forgot (or refused) to check his code before he checked it into the source code repository.

Development Best Practices for AJAX Applications
The following best practices should be enforced for AJAX applications:

JavaScript
If you're not using a server-side AJAX framework, your application is likely heavily dependent on JavaScript. It Ôs much easier to introduce errors into JavaScript code than into a compiled language because there is no compile-time check for errors. Hence syntax checking is important for JavaScript code. JavaScript's language features promote bad programming practices that can make it difficult to manage and reuse a JavaScript code base - for example, it's very easy to add global variables and methods. So it's important to eliminate these kinds of problems by continually validating that coding best practices are being followed. Browser compatibility is a huge issue for AJAX applications. It's critical to ensure that your developers aren't using browser-specific JavaScript (and CSS) features, and that your own custom browser-agnostic JavaScript methods are being called instead of browser-specific methods that could break your application in some browsers. Use an enforcement tool that automatically checks for syntax problems besides having built-in rules to look for common JavaScript coding mistakes or browser incompatibility issues. The enforcement tool should also let you easily define your own internal best practices guidelines and automatically enforce them. Examples of some custom guidelines you might create and enforce:

1. Every method or variable must be defined in a namespace
2. Use your own NodeCreator.createNode() method instead of the standard DOM methods for creating nodes to handle browser inconsistencies.

Security Policies
Security issues are more important for AJAX applications than for traditional Web applications. There are two reasons for this. First, the application logic that now resides on the client in the form of JavaScript exposes more of the guts of the application to would-be hackers, making it easier to determine how to attack the application. Second, the automatic page update mechanisms of many AJAX applications provide more opportunities for cross-site scripting kinds of exploits.

Page 1 of 2   next page »