Site MapAccessibilityContact Us

Call us at (855) 254-1164 to learn more about Enterprise

PushToTest - Open Source Test



 E-mail | Print |

14. Improving TestMaker

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.

Improving PushToTest

PushToTest TestMaker is the open-source test automation platform. This section shows how you may work with the TestMaker source code for feature enhancement and bug fixing.

Improving PTT

PushToTest TestMaker is the open-source 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

PushToTest 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 Subversion (svn) server. svn is a version control system enabling developers to work on TestMaker as a team.

The PushToTest svn 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 commit privileges. Currently, there are five committers.

The source is licensed under a GPL version 2 open-source license. Building TestMaker from source requires expert knowledge in Java, Ant, NetBeans, XML, Web services, and testing. Download the source at our Subversion repository at http://dev.pushtotest.com/svn/tm5.

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, this will enable everyone to read the code. Feel free to reformat the style 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).

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.

Reporting Bugs

Please submit bugs with example code to This e-mail address is being protected from spambots. You need JavaScript enabled to view it or by posting bug reports on the Bug Reports forum on the PushToTest web site. Bug reports with sample code are highly appreciated!

Feedback

Please e-mail general comments about Tool to: This e-mail address is being protected from spambots. You need JavaScript enabled to view it

The above email address is not a subscription list. It is simply a one-way channel that you can use to send comments to the Load development team. Please note that while we try to respond to each message we receive, we may not be able to respond to every individual message.

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