Improving TestMaker, A Developer's Guide

PushToTest TestMaker is the open-source service and application governance and test automation platform. The PushToTest runtime turns unit and functional tests into scalability and performance tests and service monitors with no extra effort.

PushToTest TestMaker source code is distributed under a GPL v2 license. The PushToTest Company distributes pre-built binaries of TestMaker under a commercial license that is free and limits the number of concurrent virtual users and service monitors.

Building TestMaker From Source

TestMaker packages bug fixes, documentation updates, and new features into ready-to-run binary distributions. Between releases, modules, object libraries, and work-in-progress code are available from the PushToTest CVS server. CVS is a version control system enabling developers to work on TestMaker as a team.

The PushToTest CVS server allows anonymous download of the TestMaker code. Updates and patches should be sent to Frank Cohen, principal maintainer for TestMaker, for consideration. With enough support Frank may choose to give you CVS commit privileges. Currently, there are four committers.

For Unix:

$ export CVSROOT=:pserver:anon@cvs.pushtotest.com:/var/cvsroot


For Windows (we recommend using a CVS client):

C:> set CVSROOT=:pserver:anon@cvs.pushtotest.com:/var/cvsroot


In both cases the checkouts are:

$ cvs login

(Logging in to anonymous@cvs.pushtotest.com)
CVS password: <ENTER>

$ cvs co tm5

cvs server: Updating tm5
...

The tm5 module includes:

Read the documentation in the docs directory to learn how to build TestMaker.

Getting Help From The TestMaker Developers

To receive email announcements when the TestMaker CVS is modified, subscribe to the cvscommits email list. Discussion among the TestMaker developers is on dev@lists.pushtotest.com. This is a good place to post questions and suggest new features.


Coding Practices

Style

More or less, the Java code format should follow the Java coding conventions as defined in Code Conventions for the Java Programming Language.

I don't want to be overly strict on this, but in general, if this style is followed, it makes it easier for everyone to read the code. If you don't like the style, feel free to reformat with a tool like 'indent', however please reformat code back to the correct style before generating and submitting patches.

Tabs or Spaces

The Religious Debate of programming. :)
Please use four (4) spaces for indentation. It is a happy medium that, hopefully, will make as many people as possible happy. Again, if you don't like coding with four spaces, please use a tool to convert to this style before making diffs or submitting patches.

Javadoc

The PushToTest team likes Javadoc. We promise to use Javadoc and expect others to use it so our API documentation is kept up to date.

Making Contributions

PushToTest is available under a license allowing you to possess and modify the source as you see fit, though you are not required to make any changes available to anyone, including us. While you are not required to submit changes, we welcome them, and if you share your changes with us, you get the advantage of having other people's improvements and fixes without needing to maintain patches against the official version.

We encourage anyone who finds a bug to report it, and we HIGHLY encourage anyone who fixes a bug to share the fix with us so others can also benefit. We also accept contributions, additional features, etc. as long as they fit into the scope of the project and don't make any unnecessary breaks with backward compatibility (though we realize it is sometimes inevitable).

Following is an outline of the best way to get a patch accepted.

Source Code

Whether you send a new file or a file patch, please make every effort to follow the code style used in the file. It makes merging much easier and the code much neater when a single coding style is used (different programming languages have different conventions, so we let the maintainer elaborate on their coding style).

Patches

Diffs are the easiest contributions for us to handle, especially if the diff is against the latest CVS sources. Diffs should be smaller by default and generally one diff per bug-fix is preferable over many bug fixes in a single diff. When they are smaller it allows us to understand the intent and to evaluate the fix more easily.

Generally diffs should be against the whole tree recursively with context enabled. This generates larger patches, but they are easier to understand.

Here are some examples using GNU diff; other tools may differ:

For a single file:
diff -c some_file.c > somefile.patch

For a whole directory (recursive):
diff -c -r tool/ my-branch-tool/

Again, a recursive diff is preferable so changes can be more easily incorporated.

Miscellaneous Notes

Some users have found TestMaker will not build on a Windows system when the path to the source code contains spaces; for example, c:\Documents and Setting\xxx. The workaround is to move the source code to a directory with a path containing no spaces.



Additional documentation, product downloads and updates are at www.PushToTest.com. While the PushToTest TestMaker software is distributed under an open-source license, the documentation remains (c) 2007 PushToTest. All rights reserved. PushToTest is a trademark of the PushToTest company.