Socket-Based Web Application Testing

This past week I was thinking about Web application testing. A business unit asked me to implement a collaborative tool. I decided to use a PHP framework. I got the system up and running but when I turned the system over to the IT group in charge they balked saying, in essence, they didn’t know PHP. There’s a whole interesting sub-story here about the don’t-use-anything-new mentality of many IT departments vs. the constantly-innovate mentality of many software development departments. However, I was mostly struck by the lack of understanding of the basic nature of Web applications. This in turn started me thinking about HTTP request-response testing Web applications. The idea here is to programmatically send an HTTP request to the Web app under test, fetch the HTTP response, and analyze the response for an expected value of some sort. Now there are several ways to send HTTP requests. A low level approach is to write code which uses TCP/IP sockets and send raw HTTP text. A higher level approach, and one which is far more common, is to use wrapper code which encapsulates much of the low-level details you have to deal with explicitly when using a socket-based approach. For example, socket-based code looks something like:
string message = // set up message
string host = // URL to Web app
IPHostEntry iphe = Dns.Resolve(host);
IPAddress[] addList = iphe.AddressList;
EndPoint ep = new IPEndPoint(addList[0], 80);
Socket socket =
 new Socket(AddressFamily.InterNetwork,
  SocketType.Stream, ProtocolType.Tcp);
string header = "POST " + " HTTP/1.1\r\n";
header += "Host: " + host + "\r\n";
header += "Content-Type: text/whatever; charset=utf-8\r\n";
header += "Content-Length: " + message.Length.ToString() + "\r\n";
header += "Connection: close\r\n";
string sendAsString = header + message;
byte[] sendAsBytes = Encoding.ASCII.GetBytes(sendAsString);
int numBytesSent = socket.Send(sendAsBytes, sendAsBytes.Length,
// set up buffered loop to fetch HTTP response stream
// analyze response
So why even consider a relatively complex socket-based approach to HTTP request-response testing when there are easier techniques? There are two main reasons. First, the socket-based approach allows you to do things you can’t do using some higher level approaches, such as send corrupted HTTP messages (to analyze security issues for example). Second, the socket-based approach adds to your fundamental understanding of exactly what goes on with Web applications. If the IT guys I worked with last week had a mindset of constantly embracing new ways of doing things, they’d likely be far more knowledgeable about Web technology and probably would not have balked at using PHP.
This entry was posted in Software Test Automation. Bookmark the permalink.