The software, a Customer–to–Customer platform for Real Money Trades (RMT) has been built as a software application, not simply a website. The strict development process is based on software quality and automation. The platform itself has transformed the concept basic auction software into a full-featured system geared specifically to MMORPG (Massively Multiplayer Online Role Playing Games). Detailed Platform Specification
The application supports the following services:
The application was later rebranded as LootXchange.
The application was deployed using Subversion and Ant. These scripts were used to not only build and deploy the application, but also used to automate other aspects of the project including unit and integration testing, back-up and recovery routines, application versionning, metrics collection and source code documentation.
We used CruiseControl.Net to manage our continuous integrate and build server.
The benefits of continuous integration include prompt resolution of issues that arise in multi-person teams; Most bugs are identified within minutes of being introduced (as opposed to days or weeks). This immediate feedback can be easily traced back to the interactions causing the failure. Continuous integration itself does not reduce bugs, but rather it is the discipline of developer testing, code coverage and analysis required for continuous integration.
The net result of continuous integration will be increased productivity by reducing the time spent chasing down integration bugs. As testing becomes the foundation for development, the application will be actually become more testable, have fewer bugs (all types) and will promote a more modular design. Quality can improve as developers are consistency working with the latest version of the code. Increased productivity can be achieved as less time is spent verifying consistency / regressions across the entire suite of applications. There are low implementation costs to achieve continuous integration as most tools are freely available as open source.
We also developed a web testing framework called WebTest to enable more efficient testing of web pages by emulating web specific attributes like sessions, requests and cookies. This module allowed most aspects of the UI to be tested using NUnit.
For aspects that could not be easily tested using NUnit, we used a testing tool called Selenium. Selenium is a replay testing tool written in an instruction-oriented domain specific language (DSL). Selenium allows for test execution performed within a browser and reflects the actual use of the application, not a simulation. Selenium is best suited for UAT, and configuration / smoke testing.
The PowerLevel application was available online from April 2005 to Feb 2007. During that time, 1080 users signed up for an account, of which 709 completed the registration process.
The software development approach to PowerLevel promoted the idea of software health. This approach to software development looks at quality as a property of software over a period of time (instead of at a particular moment in time). Automated testing helps to determine the quality at a particular moment, but additional key factors when evaluating software health include looking at properties such as: number of defects / bugs, compiling (i.e. how often build fails), running tests (i.e. how often/many tests are run), regressions (i.e. how long to fix failures), and code coverage.
By promoting consistent developer testing the internal quality of the software remains high and this promotes better software health. That does not mean the software will be defect free, but rather, dealing with these issues is more manageable.
The project had over 8000 unit tests split between five projects.
A summary of the unit testing results from NUnit is shown below.
|Note: failures are anticipated and checked for with assertions while errors are unanticipated.|
Using NCover, the unit tests above produce the following statement coverage of the application.
|Name||% Statement Covered||% Not Covered|
|*Note: The powerlevel.deploy.dll was used for testing (not a production component), hence the low coverage.|