How to Test Cookies in a Stateful Web System

[article]
Summary:

The protocol used for exchanging files on the Web is stateless, but maintaining state is essential for most Web sites. To maintain state, one option that Web developers have is to use cookies. So what happens when you delete a cookie in the middle of an e-commerce site? Rich Brauchle provides a technical background and real-world examples to help you understand how cookies work and how to test systems that employ cookies; and has some fun along the way.

My corporate duties these days at Testware Associates tend towards the managerial-responding to requests for proposals, comfortably relaxing in my corner office while others do the real work, waxing poetically in StickyMinds.com articles. However, I sometimes forego management nirvana to participate in several of the many and varied testing engagements under way. This article will focus on cookies and cookie testing techniques that Testware has employed in Web testing.

Stateless and Stateful Systems
I must start our adventure with a few textbook definitions. According to whatis.com, a stateless system has "no record of previous interactions and each interaction request has to be handled based entirely on information that comes with it." On the flip side, a stateful system does keep a record of previous interactions.

To elaborate on stateless systems, we will consider the Hypertext Transfer Protocol (HTTP), which is the protocol used to exchange files on the World Wide Web. HTTP was used by your Web browser and the StickyMinds.com Web server to display the very page you are reading now.

The Stateless HTTP
Basically, the conversation between your browser and the StickyMinds server using HTTP went like this:

Your browser: "Hey StickyMinds Web server! Can I please have the page http://www.stickyminds.com/sitewide.asp…"

StickyMinds server: "Yes. The document you requested does exist."

StickyMinds server: "Here is the text of the document:."

 

Once your browser received the last byte of this page using HTTP, the server essentially "forgot" about what you had just done. If you now go elsewhere on the StickyMinds site, the StickyMinds server responds to your new request as above, without memory of your earlier request. This isn't a bad thing for the StickyMinds site; no harm, no foul. It does not need to know anything about your earlier request in order to respond to your new request. But are there cases in which state does matter for a Web-based system?

To State or Not to State on the Web (with apologies to Shakespeare)
As we'll see, state certainly does matter on the Web! Take everyone's favorite destroyer of shareholder's equity and purveyor of books and music, amazon.com. If there weren't ways to overcome the stateless nature of HTTP and maintain state on the Web, the following would not be possible:

Figure 1

FIGURE 1 Welcome screen

  • The nice "Hello, " message that greets returning shoppers on the Amazon home page. Without state, how could the site have any knowledge of your name?
  • The virtual shopping cart. In the absence of state, how could Amazon keep track of the individual items I add to my cart and the quantity of each item?

Figure 2

FIGURE 2 Shopping cart

So, how does amazon.com work around the stateless HTTP protocol to accomplish the "magic" above? Part of the answer is cookies.

Maintaining State with Cookies
Whatis.com notes that a cookie is "information a Web site puts on your hard disk so that it can remember something about you at a later time."

How and where cookies are stored depends on the browser and operating system you use. Internet Explorer (IE) stores each cookie in a separate file, usually underneath the Windows operating system folder. Netscape stores all cookies in a single file named cookies.txt, usually in a folder underneath the browser's installation folder.

Per-Session Cookies and Cookie Expiration
When a Web server sets a cookie on your system, it can optionally give that cookie an expiration date. As time marches on, any cookies with expiration dates in the "past" are deleted.

If the Web server does not give a cookie an expiration date, that cookie is a per-session cookie. Per-session cookies

Pages

About the author

Richard Brauchle's picture Richard Brauchle

Rich Brauchle is Vice President and Co-Founder of Testware Associates, a New Jersey-based software testing consulting services firm. Before Testware, Rich worked as a software engineer for Asea Brown Boveri. Rich holds a BS in Electrical Engineering from Rensselaer Polytechnic Institute and an MBA from Rutgers University. Unless you're sending spam, he can be reached at richb@testwareinc.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Aug 25
Aug 26
Sep 22
Oct 12