(This page needs debate or consensus)

Testing / QA

As a core Java development API (and without any external system dependencies), Collections should have a set of tests that are deterministic (quasi-mathmatical) proofs of the operation of the system. Each test should stand alone.

JUnit 4

JUnit will most likely be used as the testing library as it has good literacy in the community, is what is already in use in collections (so the existing tests run without change). While TestNG is an excellent framework for testing, and does all sorts of wonderful stuff to help test "real" systems, collections is not one of those systems. All it's code is able to be tested in complete isolation from any external input, and the most complicated dependant tests are relatively simple.

Mock Objects

For testing the new version, we will be using [dynamic] Mock Objects. This is because they provide absolute isolation of the classes under test. Because the collections package is a core api, and is relatively simple, there is no need to test with fully constructed objects [and they'd get in the way over time].


(This really needs soem debate) For many of the classes, 100% coverage is warranted - CollectionUtils etc. In others, some leniency may be warranted (PredicateUtils.andPredicate). However, 100% should be aimed for as this is a core java api, and where it is not achieved, some explanation/consideration should be given.

EMMA seems to be a good fit for acheiving high coverage, as it supports the notion of partial line coverage. It's license is CPM (which I think is ASL compatible), where as Cobertura is GPL'd, and so is not suitable [or is it? this is only for building, and is not extended].

Collections/GenericCollections/DevelopmentGuidelines (last edited 2009-09-20 23:48:47 by localhost)