Package org.apache.juddi.api.impl

Unit tests to test the api implementation.

See: Description

Class Summary

Class	Description
API_010_PublisherTest	This test is jUDDI specific, as the publisher methods are an extension to the UDDI api.
API_020_TmodelTest
API_030_BusinessEntityTest
API_040_BusinessServiceLoadTest
API_040_BusinessServiceTest
API_050_BindingTemplateTest
API_051_BindingTemplateWSDLTest
API_060_PublisherAssertionTest
API_070_FindEntityTest
API_080_SubscriptionTest
API_090_SubscriptionListenerIntegrationTest
API_099_LoadTest	Load tests for subscriptions
API_100_ClientSubscriptionInfoTest
API_110_FindBusinessTest	Test to verify JUDDI-398
API_120_CombineCategoryBagsFindServiceTest	Test to verify JUDDI-456 Test does a find_service with the combinedCategoryBags findQualifier set, expects back one service with a serviceKey of uddi:uddi.tompublisher.com:servicetest02.
API_130_CombineCategoryBagsFindBusinessTest	Test to verify JUDDI-456, does a findBusiness query with combineCategoryBags findQualifier.
API_140_NegativePublicationTest	The Negative Publication tests validates adherence to UDDI's string validations, max lengths, null values (and more) by sending bogus requests to a Publication endpoint.
API_141_JIRATest	This test class provides test cases of items discovered or reported through the Juddi JIRA issue tracker The idea is that these tests apply to any UDDI registry and that the tests are either implied or derived requirements defined in the UDDI spec that were missed in other test cases for Juddi.
API_150_ValueSetValidationTest
API_160_ReplicationTest
API_170_CustodyTransferTest
TokenTest	This was created to test the features added for JIRA JUDDI-686 which implies that auth tokens can only be used from the IP address that it was issued to
UDDIPublicationImplExt	This class is for testing purposes only and enables you to override the requestor's ip address
UDDISecurityImplExt	This is used

Package org.apache.juddi.api.impl Description

Unit tests to test the api implementation. Theses tests go all the way down into the persistence layer. By default they are using an embedded Java-based database called Derby.

The order in which the tests are run is irrelevant however some tests are more basic then others. For example, you will need to have a Publisher, before you can persist a Business, and you need to have a Business before you can persist a Service. So it makes sense to test persisting a Publisher first.

By default JUnit executes tests in alphabetical order, so to control test execution order we use the JUDDI_###_ prefix.