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 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 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