Faban Next generation benchmark development/runtime infrastructure. Faban is practically the consolidation of our benchmark development and management knowledge and experience. It is a facility for developing and running benchmarks. It has two major components, the Faban harness and the Faban driver framework. The Faban harness is a harness to automate running of server benchmarks as well as a container to host benchmarks allowing new benchmarks to be deployed in a rapid manner. Faban provides a web interface to launch & queue runs, and extensive functionality to view, compare and graph run outputs. For workload developers creating new benchmarks, Faban also provides a driver framework and component model for rapidly implementing high quality benchmark drivers. The Faban driver framework controls the run lifecycle as well as the stochastic model used to simulate users for the benchmark implemented using this framework. It provides built-in support for all of the major components in Java Enterprise System as well as the Oracle DBMS. It is the harness of choice for all future benchmarks.
Open Source Testing: Link Checkers is a list of tool suites for testing web applications, each of which have link checking functionality.
-- Main.rickcarson - 07 Feb 2005
Please forgive my facetious (but only a little) addition.
I've just finished working on a web project, for which out of the half dozen developers, only one (me)
regularly ran and viewed the pages and did a basic walkthrough. Everyone else relied heavily on
automated tests - to the exclusion of all else in some cases. The regularity with which the test cases
would all pass, and yet pages wouldn't load (and yes, we had tests for forwarding) and major
functionality in other areas of the ap would stop working (even though the tests were still fine) was
very sobering.
Of course, we weren't using any of the open source tools listed above. I'm sure they all have their
strong points and weak points. There's quite a lot of them, I hope that the advocates of each will
add their point of view on why each should be chosen. I think the other developers would have
happily used any of those testing suites, so long as they were automated - the ie 'Black & Decker'
meta rule for tool selection (any tool will do, so long as its a power tool). My preference would be
for one with (at least) the following criteria:
Must be able to run tests against the code in its target environment (where you have a test environment that is sufficiently 'production-like' for this to be meaningful) - so you find out about integration and system testing issues earlier rather than later.
Must not spit the dummy over minor UI layout changes. There always seem to be these fiddly little changes that don't change the functionality of the page (ie move this control over two pixels, make this text a little more blue). If the test is strongly tied to getting a very particular html (or CSS) response then not only would you be fighting in the 'mosh pit of graphics design', but you'd spend most of your coding time fighting the tests too.