Mocking the Server Side
No, I’m not talking about making fun of a popular Java developer web site here. I just want to describe a process that I’ve found myself using in my Ajax develoment, and wondering what other people think about it.
A typical Ajax application is split across two layers. The client-side code is written in JavaScript, and the server-side code in PHP, Java, .Net, Ruby or whatever else (which is itself split into layers, but we don’t need to worry about that today). The job of the server code is to generate data feeds to the Ajax app, most commonly written in XML. The xml returned by the server can then be read by the XmlHttpRequest object as a JavaScript Document object using xhr.responseXML. (Or, yes, you could just use responseText if you’re returning JSON, say, or another form of text-based markup.)
I tend to write my client code by hand, and serve it as static .html and .js files from the server, so the server-side code has no involvement in the process beyond supplying the data feeds. I know that this isn’t everyone’s style, and I’m intrigued by the frameworks such as Backbase, Guise and some JSF implementations, that claim to relieve you of the burden of hand-coding JavaScript. But let’s stick to my way of doing things for now, because I realised that it offers an interesting advantage, the ability to mock the entire server layer.
A Mock Object is a stand-in for the real thing. Few modern programs are really standalone, and enterprise apps require a very complex context in order to operate; containers, databases, directories, web services, etc. This can make testing difficult, because to set up the test and run it, one neds to provide all the necessary context. Mock objects can be thought of as really dumb implementations of a contextual element, one that would never be useful in production, but provides the predictability and ease of setup required for a test. A mock database might always return the same four rows of data, whatever the WHERE clause. A mock web sevice might always serve up the same XML document. You get the idea? If not, there’s much more about mock objects here.
I’ve found myself using the file system as a mock server side. Granted, my position is probably as bit unusual at the moment, with final reviews of server-side code written in four different languages flying across my desk for the Ajax book. I don’t have the time to fire up a J2EE container, .Net server and a PHP system all at once, but I can test out client-side code by mocking the output of a script.
Let’s take an example, have a look at the following bit of code, written for ASP.NET using C#:
Response.ContentType="text/xml";
StringBuilder builder=new StringBuilder("<results>");
string query=Request.Params("q").ToString();
string sql="SELECT name,address FROM people WHERE name LIKE '%"+query+"%'";
//...run database query...
foreach (DataRow row in results.Rows){
builder.append("<match name='"+row["name"].ToString()+"'>");
builder.append("<address>");
builder.append(row["address"].ToString());
builder.append("</address>");
builder.append("</match>");
}
builder.append("</results>");
Response.Write(builder.ToString());
This is about as simple as things can get - I pull some data out of a table, format it as XML and write the result to the response. Getting it off the ground requires me to fire up a .Net server, and populate a database table, however.
Alternatively, I can create a mock implementation in two simple steps:
- Read the aspx file, and figure out what the XML should look like, then write a little bit by hand.
- Drop it onto a plain old web server, and modify my client code to point to the appropriate URL.
In this case, the mock XML might look like this:
<results>
<match name="dave">
<address>Stroud, UK</address>
</match>
<match name="somebody else">
<address>world</address>
</match>
</results>
I can’t test the business flow of my application using Mocks, but if I just want to see how the user interface looks or responds, or do a quick test to see how things render across a number of browsers, then I can save myself the bother of setting the server up, and just drop the client code and the mock XML into the Apache server that quietly hums away in the background on my development box.
So, my general question is, then, who else is doing this right now? Does it save you time? Does it even enforce good separation between client and server? Or is it a dangerous practice to be discouraged?
In the “old days” (even older than what people nowadays tend to think of as “the old days”..) we used to refer to this practice as “stubbing out the code”.
Anywhere that “real” code wasn’t available to “take a call”, we would fake it by writing a throwaway component to act like the missing code. Today, the missing code is more likely a missing service (database, HTTP, etc.) than just some unwritten logic, but I think that the idea and purpose are much the same.
These days I use this technique more often to stand in for HL7 responders than XML responders, since real HL7 servers are generally not accessible, being critical medical systems well hidden behind hospital firewalls.
So, generally speaking, I think that it is a useful and safe way to “move along” whenever you wouldn’t otherwise be able to for lack of access to a real or simulated deployment environment to test in.
Comment by Thomas J Lukasik — October 18, 2005 @ 8:07 pm
Seems entirely sensible to me. I’ve used the same technique and anything that allows you to develop and test a component in isolation before coming up against the problems of integrating it into a wider system has to be helpful.
Comment by Phil Wills — October 19, 2005 @ 12:52 pm
[…] e, Needs Feedback October 19, 2005 on 5:21 pm | In AJAX Programming | Dave talks about his AJAX programming ways and says: So, my general questi […]
Pingback by AJAX » Dave Talks About Client/Server Side Code, Needs Feedback — October 20, 2005 @ 12:23 am
[…] “mock” the server - so we were particularly interested in David Crane’s Mocking the Server Side blog. BTW, congrats on the book!) Despite th […]
Pingback by ntschutta.com » Blog Archive » More Foundations of Ajax — November 1, 2005 @ 2:55 am
This is exactly what I do…Mock the server side results with a file in the file system. This way it would be easy too to debug the issues with some part of the code.
Pavan keely
Comment by Pavan Keely — February 4, 2006 @ 12:39 am