SourceForge.netOrientation in Objects GmbH
About
Overview
Goals
J2EE and Test
Why frameworks
Tooling philosophy
Future
SourceForge Status
Our SourceForge Site


Products
Recorder
Player
Oracle
Workbench
Ideas


Use
Install
Support for users
Javadocs


Contribute
Work with us
Contact us
) About - Tooling philosophy )

Our Tooling Philosophy

This Toolsuite will offer IDE integration based on published and standardized interfaces (today we think about integrations in Eclipse, JBuilder and Netbeans).

To minimize the costs of development and at the same time as a sign of our believe in the special value of open source software development we would like to intensivly reuse and integrate existing open source systems.

Since Apaches project Cactus develops software for the unit test of Java server applications, we will orient particularly towards Cactus.

The development of special tools for the test process is always an investment. Its return can hardly be measured (The value of an existing test tool can be easily be estimated in comparison with costs of manual execution of tests.). Often a tool development runs out of a projects initially planned budget and is cancelled by the management in the planning phase. We dont't have a budget anyway so we have to look for remarkable cost reductions.

Bugkillas tools will only be implemented by not reinventing some wheels to often. Thats why usage and development of test tools in the Bugkilla project strictly follows some rules:

  1. Define clearly what is a tools job.
  2. There is always a "tool doing the job right". A project team has to find out, how to use it right.
  3. If no "tool doing the job right" could be found by the team, the extension of a tool found during the evaluation is the solution.
  4. Integration of "tools doing their jobs right" is the key to lasting success.

Rule 2 implies that a project team has to search for a tool with a clear goal (implied by rule 1). Either the search is rewarded with success or

Rule 3 can be followed with the withdrawn candidates. We follow this procedure because we strongly believe that in almost every case "Buy is better than Make". The relation between rule 1 and 4 is, if there is need for a tool it is important to define the requirements for it in a very clear way first. Features of tools are often a kind of marketing as they produce new needs by their users. Let the "tool doing the job right" satisfy your requirements and do not use the triggering tool blindfolded by "its cool ideas".

Currently used Tools

We use the following tools as integral part of bugkilla:
  • JUnit
  • httpUnit
  • JTidy
  • Apache Cactus
  • JDOM
  • eclipse IDE

These tools are used for development or as test environment:

  • Sun WAF
  • eclipse IDE
  • various eclipse plugins
  • Apache Tomcat
  • Apache Ant
  • Apache Struts
  • JBoss
  • cvs