Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by KelvinGoodson: http://wiki.apache.org/ws/Tuscany/TuscanyJava/Tests/RogueWave/Samples ------------------------------------------------------------------------------ A place for jotting notes on how the RogueWave sample tests fit in with the current Tuscany set up. === general points === - Tuscany currently expects all test case classes to end with "TestCase" + Tuscany currently expects all test case class names to end with "TestCase" In Tuscany, we don't use the INSTANCE singletons in tests wherever possible, since they can cause cross test interference especially when using maven, since maven builds an ubertest, and so there is more scope for one @@ -11, +11 @@ We should consider the use of suites of tests in our test architecture - We can use TestHelper as a prototype for abstracting away common operations -- I have made a first pass at this. + We can use RogueWave's TestHelper as a prototype for abstracting away common operations -- I have made a first pass at this. We must identify and separate implementation specific tests, such as testGetAttribute()'s method. {{{ @@ -28, +28 @@ How about once we have done an initial pass on abstractions of test utilities we require the implementor of a new utility method to implement a mockObject method before inserting the new code into svn. Maybe we could have an abstract base class for this, with mock object methods wherever there are gaps in one or more implementations. The base class using mocks should signal in the test log that mock objects are being used. We could even use assertions in the mock method to document what must be true of a true implmenetation of the utility method. - We need an abstraction or a common policy for locating test data. In tuscany we tend to do this by having resources available to the class loader. This currently causes all tests in the XMLDataObjectTest program to fail. I have this compiling cleanly, (with a few tests commented out). + We need an abstraction or a common policy for locating test data. In tuscany we tend to do this by having resources available to the class loader. The RogueWave method currently causes all tests in the XMLDataObjectTest program to fail; it would work if I got the test data and oput it in the right place, but it's a bit fragile. BTW, I have this compiling cleanly, (with a few tests commented out). === DataObjectListTestCase === It would be good to discuss the intentions of the createTestObjectTypes method. - It highligts some conventions we could adopt in type/property naming, to keep thiongs clear, and I'm + It highlights some conventions we could adopt in type/property naming, to keep things clear, and I'm not sure what's there is what was intended. + + I have annotated my local code ... + + {{{ + /* + * create type system + * catalog2 + * - product2:DataObject[isMany:true] + * + * product2 + * - nameTest:String + * + * my guess is that the intention is + * catalog2 + * - product2:product2(isMany:true) + * - nameTest:String + */ + }}} + + Frank looked at this on 26th October and put a note on Tuscany-829. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
