starzero: an ideacandi playground

This has been an ongoing interest of mine ever since I started developing server side Java extensions for Smartfox.  As part of a responsible development methodology, Unit Testing is a very important facet to ensuring a product that meets strict quality assurance standards.  Combine this with some sort of continuous integration that will perform these tests for you and you have the makings of a well put together development cycle that includes development, testing, and deployment.  As many who read this will no doubt be aware, unit testing of an extension developed for the Smartfox Server can prove to be a difficult task.  This is mostly due to the decoupled asynchronous (event based) communication structure that is designed to allow dialogue between your client application and the Smartfox Server.  Anyone familiar with nUnit Unit Testing frameworks will realize that they are built to perform synchronous tasks with a strict beginning (setUp) and end (tearDown).  This presents an issue because of the previously mentioned problem of asynchronous communication.  We can, however, begin to move closer to a good solution of testing by “faking” an asynchronous call to the server and have a convenient runner attached for easy firing of multiple testing facilities.  The question of Unit Testing extensions has been covered several times in the Smartfox Server forums with a very good suggestion by Lapo to decouple your extensions in such a way so as to perform localized testing procedures on the specific methods that you will use directly in an extension (that is to say that you use some sort of decoupling pattern such as DAO).  However, I have personally found myself in situations many times that require me to develop for a client (Flash / AS3) application that I will not be able to test against because, frankly, the code for that piece has not been written yet.  I would like to have a formalized way to look at and / or validate against communication that is prompted by my extension.  If I can do this in a repeatable “automatic” way, all the better.  I have found that by extending the JUnit framework, this is possible.  Keep in mind that you will be validating input against whatever protocol you have chosen for your exchange between client and server.  At present, I believe this includes raw (with a delimiter), xml, and json.  This means that you will need to develop the logic necessary to verify that your expected input is correct.  This will be one of the improvements that I would like to make to this project, a library that adheres to the protocol specification for communication in xml and json.  At the very least, this will lend a formalized way to view debug communication across the network.  This is probably a good place to let you know that you will want to be fairly experienced with the JUnit testing framework in order to implement this solution as it is beyond the scope of this article to explain how to set it up.  In addition there are many articles that are more than adequate to explain this.  I will say, however, that I enjoy the integration of JUnit with Eclipse and it lowers the  barrier to entry quite low.

I will share the code that I have written thus far at the end of this post, but I must stress that this is a rough draft, if you will, that I intend on improving over time and would like to get feedback on.  Consider this the first foray into a community effort to bringing repeatable reliable Unit Testing to Smartfox extensions. 

From looking at the code, you will see that it is rather simplistic in nature.  This is what I like about it.  If Unit Testing requires too much work (read, more work than developing the application that you are testing against) then it will lead the programmer to most likely eschew testing for more important tasks, not the least of which shipping code on time (and on budget). 

As a brief overview, in no uncertain terms, I extended the base TestCase class and simultaneously implemented the ISFSEventListener interface to facilitate the listening for events that are fired as a result of many of the basic tasks required to connect to Smartfox.  I have relied primarily on the Java client API to achieve all of the client methods required to make this testing possible.  If you will notice, my effort to “fake” an asynchronous challenge / response with Smartfox is achieved through a sleep state during specific steps of the JUnit testing lifecycle.  Also, please notice that another sleep is required after a call to an extension in each of your testing methods.  I realize that this could be handled in a much more elegant manner through the use of a Timer (perhaps) and this is first on my list to improve.  The project that I am currently working on has very little latitude with respect to time allowed for tasks such as this, so I am forced to develop a lot of this during my “free time”.  If there are other improvements or requests for a feature let me know in the comments or at the forum.  If this gains any amount of popularity, I will host it on Google code to formalize its development.

With that I will leave the code for you here to download.  Enjoy and feel free to talk back.

Share on Facebook

In the second of, what I hope to be, a series of posts on the topic of Smartfox, I want to talk about the overall design methodology that I have adopted and my reasoning behind it.  Firstly, I would like to make this very open to comment.  Please feel free to critique and / or share any of your own comments or ideas to this.  Widgetizing this process and distilling it down to a series of best practices can be beneficial for the community as a whole, as has been demonstrated countless times in the open source world. 

I have the privilege of working for one of the only companies (that I am aware of) in Tennessee that is actively engaged in the virtual world / fully interactive space.  Early on, we evaluated several products for our latest interactive project (more details as soon as I can share them) and finally came to the conclusion that Smartfox was the most advanced at the time and, with continual improvements, could prove to be highly beneficial to work with (I can dive more into our decision here, if someone would like me to).  My chief responsibility for this project is to be the technological glue that fits all of the myriad of pieces together that are required to get one of these things out the door (not to mention the development of all of our server side code in Java and site code in PHP).  If you have ever been to sites like Club Penguin or Football Village, you may think that they are relatively simple applications that require little to no expertise in design and execution.  This could not be further from the truth, as I have come to learn first hand.  You have to be prepared to implement a solid methodology that emphasizes a large degree of transparency and communication between (ideally) design and development teams.  You are required to architect an application that can scale very quickly while working within what may seem like unbelievable deadlines.  This is not altogether uncommon with anything in the overall software development industry, particularly for web based applications.  I would say that this is simply magnified by the complexity that is involved in your core offering (which, again, is largely a common challenge).  As we began our discovery (next section), we found that there was a significant amount of complexity in some of our core requirements.  With all of that said, let’s dive in to what has been implemented thus far during this project.

There was a significant amount of time spent on discovery in the first stages of development.  This was mainly to draw up a working functional specification that the developers (myself and my teammates) could use to drive decisions on how a specific feature would be built and how the overall system architecture would be implemented.  Furthermore, a significant amount of wire framing was down early on to, firstly, give the client an idea of what the product was going to look like and, secondly, to give our design team an idea of what they were going to be building.  As an aside, I would say that before beginning any project of this magnitude, a functional specification represents the bare minimum in preparation, if you wish to be successful.  Make your spec as feature complete as possible but realize that, being as agile as you can be (waterfall is for weenies), there will be changes, omissions, and additions.  I decided early on that we would need a fairly beefy development server with which to test our product, so we decided on a Dell Poweredge 64-bit machine (knowing that, eventually, this would live in a managed environment). 

Our feature needs and overall complexity in what we were going to accomplish (and, more importantly, the time restraints given to accomplish said features) required that we use the Smartfox extension interface to its fullest potential.  I write our extensions in Java with the client side code being written by the rest of the development team in Actionscript 3 and designed by our very talented illustrators and animators in Flash CS4 (yes, we have all the new toys).  I also decided to adopt an ORM in favor of the built in JDBC interface that comes, by default, with Smartfox (please see my earlier post to see how that is set up … not too terribly difficult).  The main reason behind that decision was for one of code portability and readability which is, quite honestly, only a couple of reasons for choosing an ORM solution (who really wants to see SQL in their code anymore?).  I, long ago, adopted Eclipse to be my IDE of choice for all of my open source projects (which mainly consists of PHP) mainly because of its support for code completion and debugging (the xdebug support really sold me … and given that its free, the irony is not lost on me in that statement).  I was a long time VIM guy (and still am, to a large extent), but had to relegate myself to the realities of the world I live in which requires a good degree of productivity apart from the toys that I get to play with.  Equally attractive with the Eclipse project (perhaps more so) is its support for the Java programming language.  It has made development in Java a breeze allowing me to focus solely on the language semantics (and later , the Hibernate ORM) rather than the complexities of project construction (think ant vs. maven) and deployment (although a fair amount of thought was placed in that … more in a minute).  Thanks to its excellent debugging tools, I was able to set up my environment (here) to debug my Java extensions real time.  That, by far, has been the most indispensable tool.  I chose MySQL for our database backed simply for its ubiquity and ease of use.  I have a lot of experience with MySQL and am comfortable optimizing it for scalability.  There are many different database products on the market today, both free and commercial.  You would be right to do your research and find the product that is right for your project needs.  Finally, we have a website component to the project (as is most often the case) for which PHP, Apache, and the Zend Framework (don’t hate) was chosen.  We are employing a true pure LAMP stack here.  I chose Centos 5 for the underlying OS mainly because that is what I am most comfortable with.  Linux distribution availability and their sometimes religious following fall within the same realm of opinions and arm pits (as the old adage goes).  Go with what you are comfortable with and are prepared to admin when the heat gets turned up.  In keeping with the idea of continuous integration, I am employing the Xinc project to periodically run Phing scripts in the event that a change has been made to the Subversion repository (did I mention that you HAVE TO HAVE a version control system?).  It is important to be able to support a simultaneous design and development workflow even down to the organization of your file system.  At the same time, you don’t want to have a significant challenge in deployment.  This is where Phing comes in.  You can structure your packages and design files in ways that make sense for each respective team and simply write a script to bring the pieces together into a cohesive project.  For example, we have a dev section in our repository.  Inside there, we maintain our web, java, and as3 structures independently of one another (although, they have to play nice at some point).  When the time comes to submit our new changes to the repository and we are ready for full site integration testing, Xinc will sense the change at the next build cycle and push that to where it will ultimately live in some public location that Apache can serve (of course, if you simply can’t wait, you can always run the build script manually).

This brings me to the conclusion of this particular post because as I write this, I am now realizing that there is a significant amount of information that I have left out concerning the real deep stuff that I want to talk about (mainly, the interplay between the client and server development).  As a result, I am going to stop here and break the deeper stuff our into another post, or two.  Please leave suggestions and / or feedback!  What does your team employ to facilitate the development of your multiplayer games or interactive projects?

Share on Facebook