ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "Tuscany/TuscanyJava/Tests/RogueWave/Samples" by KelvinGoodson
Date Mon, 30 Oct 2006 14:53:53 GMT
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: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message