Difference between revisions of "Stanford:Tools"
m (2 revisions: Import from CF Pages)
Latest revision as of 12:21, December 16, 2010
Description and Rationale for Tools
This page is intended to give an overview on the systems and to describe why we selected particularily this set. How to install, operate, and use this tools is described in
Hudson is a server application to automatically and continuously build, test and deploy one or more projects. It provides an overview on the build and tests results including code metrics, architecture metrics, JUnit results and much more.
It is obvious that such repetitive tasks should be automated. However, there are several products to facilitate this task. Among those there is CruiseControl We decided to prefer Hudson over CruiseControl for the following reasons:
- Installation is simpler. It is just download the jar file. E.g. no installation of DB necessary.
- Administration is simpler: An easy to use web interface gives access to all administrative settings
- Easy integration with other tools e.g. with Sonar, TestNG and communication services
- Related to Plug-ins
- Easier plug-in development
- More plug-ins available (e.g. twitter, email, Sonar, Selenium)
- Easier plug-ins administration
Hudson executes the Maven script(s) including builds as well as unit and UI tests, triggers reporting and communication of build and test results.
<Link>Instruction how to install and configure Hudson.
As more libraries a project requires and as more dependencies these libraries have as more complex the setup of a new development environment and of executing a build become. For example WebProtégé has dependencies to Protégé, to the Google Web Toolkit, to Apache libraries, and so on. And even the referenced libraries are interdependent.
Maven is capable of resolving these dependencies. Nexus is a repository manager which allows you to centrally provide these libraries in a versioned and reproducible manner. Nexus also can serve as proxy. So the developers (and the build system) just need to retrieve these files from the repository instead of individually downloading these artifacts redundantly. This not only saves bandwidth, but also reduces the load on “Central” (the central Maven repository).
Nexus is not replacing Maven. Nexus proxies the Maven requests to a central Maven repository. Nexus provides as the feature not only to proxy repositories, but to operate our “own” repository which is the deployment target of all of our projects. Please note that Maven itself uses a repository (the Maven repository).
Further feature of Nexus include
- a quick and easy search of all artifacts.
- Developers don’t have to have the entire source. They just can work with libraries from Nexus. This makes collaboration easier.
- Clear responsibility and maintenance of “official” 3rd party libraries.
An additional list of reasons for using repository managers can be found at http://www.sonatype.com/books/nexus-book/reference/sect-repoman-reasons.html.
A comparison of repository managers (Apache Archiva, Artifactory, and Nexus) can be found at http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix.
“Standard” developers not necessarily have to deal with Nexus. She just uses Nexus as a repository to retrieve artifacts from. If she requires a new jar-file, this has to be done as described in the How-Tos. However, we recommend to have a local repository as well.
<Link>Instruction how to install and configure Nexus.
Sonar is a very powerful platform to report the quality of software products considering aspects as
- Code metrics as complexity
- Error/bug patterns
- Architectural metrics
- Conformity with coding guidelines
- Results of tests (Unit tests, UI tests) including errors, failures and code coverage.
Sonar provides both, a comprehensive overview on the quality o projects as well as the option to drill down to single metrics/aspects and even to the single line of source code.
Sonar serves as shell compiling and consistently visualizing the results of numerous tools as Checkstyle, FindBugs, PMD, and TestNG .
<Link>Instruction how to install and configure Maven.
We prefer TestNG over JUnit for the following reasons:
- Better separation of test code and test data
- Better grouping of tests and re-use of test groups
- Better support for parallel (multi-threaded) testing
- TestNG automatically produces test reports without having the need to use other tasks as JUnitReport.
Maven is used by
- Developers to initially create his workspace (initial build)
- To define the build and test process which is executed and scheduled by Hudson.
<Link>Instruction how to install and configure Maven.
- prepare-package (maven 2.1+)
We prefer Firefox over other browsers for two major reasons:
- Firefox is available on LINUX, too. LINUX will be our server OS.
- There is a Selenium Plugin available for Firefox.
Having said this, it is nevertheless worth mentioning that the web applications have to be tested on other browsers as well. This requires no plugin. The plugin is only required for automated UI tests.
Selenium Server (Selenium Remote Control)
Selenium remote control is a server which allows developers test web applications (even with AJAX) using Java code (e.g. JUnit, TestNG) or any other language.
Selenium RC automatically launches the browser, simulates the user actions and kills the browser afterwards. Thereby Selenium RC facilitates the complete test automation ($rarr; regression testing) of rich web applications.
<Link>Instruction how to install and configure Selenium.
Selenium Plugin (optional)
The Selenium IDE is an optional Firefox plugin which helps developers to record actions in the browser and generate Java code. However, the capture & replay functionality is very limited. Therefore Selenium tests will be written as regular Java respectively TestNG code.