In: Categories » Computers and technology » AJAX » Testing the Client Side Logic
Problem You want to effectively test your application’s client-side logic. Theory Testing GUI code tends not to be a productive task because of the complications that arise. The main complication is how to test the correctness of a user interface. Imagine a situation where clicking a button causes a table to be filled with data. Now imagine that when a check box is checked and the button is clicked again, a different table is filled with content. The fact that clicking the same button results in two different generated outputs is frustrating and complicates GUI testing. One of the main reasons why testing a GUI is complicated is because the GUI is a black box, and the user cannot access the individual GUI elements. RealPlayer is used to play some media file. Imagine running a media-file generation service. Testing the format of the media is not a problem and is akin to testing the contract. You also need to test if a client such as RealPlayer can consume, process, and display the media. Figuring this out requires taking a snapshot and then checking if the bits and bytes are displayed properly. Thus, you’re left wondering how to test the functionality of your data stream when played in RealPlayer. The simplest but probably most expensive and error-prone solution is to have a human look at RealPlayer and say, “Yes, the content is being played,” or “No, the content has problems.” A human could carry out the same tests repeatedly and then verify whether the tests worked.
The problem with getting a human to do this is that humans make errors when doing the same thing over and over again. Humans are not incapable of doing the same thing over and over again, but they get bored and the mind wanders. Humans are much better at spotting problems if the menial work is replaced with automation. Automating the testing of RealPlayer is difficult, because RealPlayer is not under your control. It is programmed using a traditional programming language. Traditional programming languages create black boxes that a user cannot get around. In the old days of Windows 3.1, an application could access another application’s window handles. That ability made it possible to do interesting things, but the cost was that hackers could wreak havoc on an application. Today, applications are not allowed to access another application’s GUI elements willy-nilly. Solution The only effective way to test a GUI is to have access to the source code and test the layer that the GUI calls. The idea is not to test the GUI, but rather to test the logic that the GUI calls. Of course, this only works if the GUI layer contains absolutely no logic and no state. This is more complicated because it means that the GUI is a copy of the state held in memory. Many developers consider this a good thing, and I’m not about to debate the merits or problems of this strategy. Instead, I want to highlight that Ajax and DHTML applications are unique in that they allow you to have your cake and eat it too. With DHTML, two completely unrelated HTML pages can communicate with each other and slice and dice each other’s data. In a traditional programming approach, you wouldn’t like to have other applications changing your look and feel to suit their needs. Yet this is an inherent behavior of DHTML. This feature can be put to good use when creating tests.
The browser window in the upper left-hand corner is the test controller, which contains a number of buttons used to test individual features. The test controller button Test Get Document is used open a new instance of the HTML window to be tested. It assigns the instance to the script variable testWindow. When clicked, the button Test Add executes the method TestAdd, which then calls a method DoAdd defined in the new instance of the HTML window. This is a unique feature of DHTML, in that one HTML window can reference elements in another HTML window even though both windows are unrelated. The test controller uses the identical testing routines as outlined in the “Coding the Contract Using Test-Driven Development Techniques” section. The test controller example uses the calculator example. To be able to test the calculator application, copy and modify the empty template file that represents a test. Add the three tests used to verify the correctness of the calculator. There were two unique contracts in the contract recipe.
The additional test is the test to open a new window that will load the initial HTML page used to add two numbers. The modification of the template test page involves adding some tests, as well as some user interface elements used to instantiate the tests. I won’t focus on the user interface elements, as the details have already been explained in the “Coding the Contract Using Test-Driven Development Techniques” section. Instead, I’ll focus on the tests that are executed, as they are unique in that they don’t use the XMLHttpRequest object directly. The tests execute functionality in the other HTML page. In the following implementation of the testsToRun variable, note that the declaration has been abbreviated for clarity purposes.
legal notice
Our website is not responsible for the information contained by this article. Web-articles is a free articles resource.
Suggestion: If you need fresh, daily updated content for your website, feel free to use our service. Click here for more information.
Useful tools and features
If you like this article (tutorial), please link to it from your web page using the information above.
related articles
Given the recent interest in Ajax, you’d be forgiven for thinking it was a new technology. In fact, the XMLHttpRequest object has been around for years. In technical terms, asynchronous JavaScript interaction with the server is nothing new. All of the other elements of the Ajax model have also been around for quite some time: CSS, (X)HTML, and DOM Scripting. Yet in 2005, interest in this methodology soared. Could it really be that simply giving this approach a snappy name like Ajax was responsible for the sudde...
2. Understanding the Definition and Philosophy of Ajax
The focus of this article is to provide solutions to some common, general problems and questions that are bound to arise before or during development of Asynchronous JavaScript and XML (Ajax) and Representational State Transfer (REST) applications. These common questions are not always technical in nature, often leaning more toward theory or philosophy of development. The problem with these kinds of questions is that once you begin to think about them, you keep going in a circle and end up where you star...
3. Understanding the Definition and Philosophy of Web Services and SOA
Understanding the Definition and Philosophy of Web Services and SOA Wikipedia offers the following definition of Web services:4 The W3C defines aWeb service as a software system designed to support interoperable machine-to-machine interaction over a network. This definition encompasses many different systems, but in common usage the term refers to those services that use SOAPformatted XML envelopes and have their interfaces described by WSDL. For ex...
4. Understanding the Definition and Philosophy of REST
Understanding the Definition and Philosophy of REST REST is a controversial topic among Web service enthusiasts, because it’s considered to stand for the opposite of what Web services and SOA are trying to achieve. The problem with this thinking is that REST is not in contradiction with the abstract definition of SOA and Web services. REST is in contradiction with technologies such as SOAP, WSDL, and WS-* specifications. The following offers a quick definition of REST:...
5. The Easiest Way to Get Started with Ajax and REST
The Easiest Way to Get Started with Ajax and REST Problem You want to know the best way to get started with writing Ajax and REST. Solution When developing an Ajax and REST application, you must decide on the tools and frameworks you’ll use. The choice is simple: Use whatever you’re using today, and write some Ajax applications. You don’t need to change the tools you’re using today. Whether you’re using ASP.NET, JavaServer Pages (JSP), PHP, Ruby, or Python, you...
6. Testing a Dynamic Contract with Ajax
Coding the Contract Using Test-Driven Development Techniques Coding the contract using agile and test-driven development techniques requires writing a number of tests and implementing aMock URL layer. Problem You want to code the contract using these development techniques. Solution To demonstrate, let’s define a use case, implement the use case as a contract, write a test case(s) to implement the contract, implement the contract in the Mock URL, and finally...
7. Understanding JavaScript and Types
Understanding JavaScript and Types Problem You want to work around the fact that JavaScript does not have types declared for its variables. Theory JavaScript code does not have any variables with a declared type. The lack of typed variables is apparent when you declare functions. That said, not having typed variable declarations does not mean JavaScript has no types or no type safety. Let’s start out with the simple declaration of a function, as illustrated by the following ex...
8. Coding Using Conventions and Not Configurations
Coding Using Conventions and Not Configurations Problem You want to make your JavaScript constructs more efficient by applying the Rails “convention over configuration” principle to them. Theory You may already be familiar with the programming platform Ruby on Rails, which is used to build Web applications. The focus of this recipe is not Ruby on Rails, but one aspect of Ruby on Rails namely, convention over configuration (see http://en.wikipedia.org/wiki/ Ruby_on_Rails for m...
9. Advantage of parameterless functions in JavaScript
Using Parameterless Functions Problem You want to take advantage of parameterless functions in JavaScript. Theory JavaScript functions for the most part have parameters. You may think that the previous sentence states the obvious after all, without parameters, what data could be passed to a function? JavaScript has the ability to declare functions that have no parameters, even though the caller of the function has passed parameters to the function. For example, let’s look at...