Projects

testability-explorer

Quick LinksGetting Started | How Testability is determined | How to Contribute | Scores for Open-Source projects Sample ReportsSource-annotated Report Testability-explorer is a tool which analyzes Java bytecode and computes how difficult it will be to write unit tests for the code. It attempts ... [More] to help you quantitatively determine how hard your code is to test, and where to focus to make it more testable. Testability Explorer can be used: As a learning tool which flags causes of hard to test code with detailed breakdown of reasons. To identify hard to test hair-balls in legacy code. As part of your code analysis-toolset. As a tool which can be added into continuous integration that can enforce testable code. Currently the tool computes: Non-Mockable Total Recursive Cyclomatic Complexity. Cyclomatic Complexity is a measure of how many different paths of execution are there in the code. It is computed, by counting the if, while, and case as branching primitives. It is recursive because cost of the method as well as any methods it calls are counted. It is total because cost of object construction as well as any static initializations are counted. And finally, it is non-mockable because any code which can be mocked out in test is not counted as part of the cost. This means that the score is based on the amount of complex code that cannot be mocked out in a unit test. Global Mutable State. Counts the number of fields which are globally reachable by the class under test and which are mutable. Mutable global state makes testing difficult as tests are not isolatable, the global state needs to be set up and cleared between tests. Law of Demeter. This is the principle that calling methods on objects you get from other collaborators is trouble, instead, the collaborator should call that method itself. It makes testing harder because your mocks must expose some internal state through these methods. Check out the Readme, or post a message to the mailing list. For a demo of testability-explorer in action see http://testabilityexplorer.org/report [Less]

debmarshal

Debmarshal is a Debian repository management system. It is designed to manage a set of local release tracks of modified and additional packages on top of a full public repository (eg. Debian/sid, Ubuntu/dapper, ...). The local database is Berkeley DB for speed. Packaged file overlaps and ... [More] undeclared dependency problems can be detected. Multiple labels and permanent numbered snapshots are a feature of debmarshal managed repositories. [Less]

Kyua

Kyua (pronounced Q.A.) is a framework to easily develop and execute automated tests for software projects. Kyua is intended to be a replacement for the Automated Testing Framework (ATF). The code base of ATF is very hard to extend and the overall design of the tools make it impossible to ... [More] implement some features highly desired by users. Kyua will start by replacing the runtime tools atf-run and atf-report with a single, integrated CLI binary, and later will provide replacements for the C, C++ and Shell bindings. In comparison to ATF, the Kyua project is also intended to provide easier access for contributions and new developers. To do so, it uses the off-the-shelf solution for collaborative development provided by Google Code and the Subversion version control system for its source code. [Less]

pyrering

PyreRingTestrunner to manage command line test scriptsObjectiveThe goal and inspiration for PyreRing is to develop an open source test runner that will execute scripts intended to act as individual test cases. We hope that it will simplify the writing of test cases by adding the functionality ... [More] , flexibility, and reduce unnecessary complexity. By removing the administrative burden that often surrounds testing, the test author can focus on writing meaningful, direct, and useful test cases. It is hoped that any project can quickly and easily install and use PyreRing with minimal knowledge of how this test harness works. BackgroundPyreRing was born out of frustration of maintaining a host of unrelated test cases. Countless days have been spent attempting to assimilate the various results, keep track of different requirements, and differentiating test cases failures from harness errors. PyreRing is written in Python. Python was chosen because it is easy to understand, powerful, and quite frankly it's fun to play with. This in no way limits what your test cases may be written in. As long as you wrap your test cases with a Unix shell or scripted language wrapper, it will be executed. PyreRing's strength lies not just in running the individual test cases that you've created; it's capable of running the resulting test suites that are comprised of the battery of test cases that you've produced. Furthermore, PyreRing will add the following capabilities: Set a timeout value Send reports to email addresses Automatically organize your test cases by filesystem directories or suite files that you define Create automatic suites based on a predefined block in your test scripts Captures standard out and standard error into a comprehensive log Developer TeamThe developer team consists of: Mingyu Wu - lead developer KD Lucas - developer and product manager Emily Tai - developer Matthew Springer - developer ContactFor general questions, feel free to contact us at: pyrering-discuss@googlegroups.com If you're interested in helping to develop PyreRing, you may contact us at: pyrering-dev@googlegroups.com This work is licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License [Less]

google-oaf

The Open Automation Framework is a perl automated testing system to help you create, manage, and run automated tests on your software projects.

cmockery

There are a variety of C unit testing frameworks available however many of them are fairly complex and require the latest compiler technology. Some development requires the use of old compilers which makes it difficult to use some unit testing frameworks. In addition many unit testing frameworks ... [More] assume the code being tested is an application or module that is targeted to the same platform that will ultimately execute the test. Because of this assumption many frameworks require the inclusion of standard C library headers in the code module being tested which may collide with the custom or incomplete implementation of the C library utilized by the code under test. Cmockery only requires a test application is linked with the standard C library which minimizes conflicts with standard C library headers. Also, Cmockery tries to avoid the use of some of the newer features of C compilers. This results in Cmockery being a relatively small library that can be used to test a variety of exotic code. If a developer wishes to simply test an application with the latest compiler then other unit testing frameworks may be preferable. For more information check out the manual and the discussion group [Less]

testability-metrics

We have moved..... http://code.google.com/p/testability-explorer http://TestabilityExplorer.org Author Blog: http://testabilityexplorer.org/blog

google-testar

Testar is a tool designed to reduce the time spent running large Java unit test suites. It runs on top of JUnit and automatically selects individual tests to execute based on what tests previously succeeded and what changes you have made to the code since then. Additionally, Testar allows you to ... [More] find out which methods a given test covers, and vice versa. [Less]

Granslator

Granslator is a windows based program for interacting with Google Translate service. Granslator make it easier for you to translate with Google!

thread-weaver

Thread Weaver is a framework for writing multi-threaded unit tests in Java. It provides mechanisms for creating breakpoints within your code, and for halting execution of a thread when a breakpoint is reached. Other threads can then run while the first thread is blocked. This allows you to write ... [More] repeatable tests for that can check for race conditions and thread safety. See the "Wiki" tab for a Users' Guide. For full documentation, please see the "docs" directory on the source tree, or in the main zip file on the Downloads page. The source tree also contains several examples of common race conditions, and shows how to test these using Thread Weaver. [Less]