Created: (MRM-1392) Separate webdav unit tests and integration tests

Add unit tests and refactor code

Cannot run individual integration tests anymore

Did a bit of unit test hacking while on the plane last night. Just  
checked in some pretty good early results. We are still bound by JUnit  
3 lifecycle simplicity and have to use static singletons, still I was  
able to build a little framework for dependency injection into the  
test cases, with access to the new DI Cayenne stack. Underneath that  
is an old CayenneResources singleton that loads DB connection,  
generates the schema, etc...

Still the unit test "frontend" is now drastically different (see e.g.  
DataContextEJBQLConditionsTest, one of the few tests that I switched).  
Tests extending DICase (or its subclass - ServerCase) can use @Inject  
annotations to get access to the interesting parts of the stack being  
tested (in 90% of cases that I converted so far this would be  
ObjectContext and DBHelper) in a clean manner that does not obfuscate  
the test purpose. I also replaced Spring/XML data sets with DBHelper.  
So a typical DB-aware test case may look like  
DataContextEJBQLConditionsTest:

@UseServerRuntime(ServerCase.TESTMAP_PROJECT)
public class DataContextEJBQLConditionsTest extends ServerCase {

     @Inject
     protected ObjectContext context;

     @Inject
     protected DBHelper dbHelper;

     protected TableHelper tArtist;

     @Override
     protected void setUpAfterInjection() throws Exception {
         dbHelper.deleteAll("PAINTING_INFO");
         ...
         tArtist = new TableHelper(dbHelper, "ARTIST");
         tArtist.setColumns("ARTIST_ID", "ARTIST_NAME");
         ...
     }

     protected void createDataSetXYZ() throws Exception {
         tArtist.insert(33001, "B");
         tArtist.insert(33002, "A");
         tArtist.insert(33003, "D");

         tPainting.insert(33009, 33001, "X", 5000);
         tPainting.insert(33010, 33001, "Y", 5000);
         tPainting.insert(33011, 33002, "Z", 5000);
     }

     public void testSomething() throws Exception {
         createDataSetXYZ();

         // normal unit test goes here
         ...
     }

It is much cleaner than what we had before at the unit test level at  
the expense of a few trivial DI providers in the DI backend.

In general I feel like the Cayenne DI container is a cool little piece  
of technology that will take us pretty far in many areas of the  
framework. It is still only 36K in size and has simplicity as its main  
design paradigm. The only major feature that it is missing compared to  
the other guys is method interception, and we can add that down the  
road if we feel compelled to have it for Cayenne uses.

Cheers,
Andrus

Hello all

I have quick question: Is there mocking framework in project?
Writing dummies for unit tests is quite useless and boring thing. Plus
it¹s
filling codebase with ³noise².
I have some experience with:
 
JMock - http://www.jmock.org/
EasyMock - http://easymock.org/
Mockito (my favourite) - http://mockito.org/

First one hasn¹t updated since Feb 2009, so I think it¹s  not a good
idea to
look there. Two others are great: both have dynamic proxying for
interfaces
and classes.

update c unit tests to ensure "zombie" java server processes don't cause
failure

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

Carl Steinbach updated HIVE-209:

Move out components specific to repo proxying in webdav module to a
separate module to the point where it can be turned on and off as a module

    [
https://issues.apache.org/jira/browse...6#action_12889216
] 

Patrick Hunt commented on ZOOKEEPER-820:

See
<http://hudson.zones.apache.org/hudson...s/759/changes>

Changes:

[justin] SLING-1569 - fixing the handling of the WeakReference hint. Uses
reflection to avoid dependency upon JCR 2. If reflection fails to find the
method (i.e. this is running on JCR 1), a Reference property is created
instead.

See
<http://hudson.zones.apache.org/hudson...taller.it/74/>

C: Build and pass tests on Win32

SPI-Fly needs itests subproject - a project with Pax Exam tests

Add javaee6-testsuite to include new tests about java ee 6 new features

Use  forkMode=once for the surefire plugin to significantly speed up tests

remove ugly warnings running tests since upgrading to jetty 7

Running tests with 'testcase' cause triple execution of the same test case

IOException throws and it fails with token expired while running the tests.

Ruby tests should not leave lang/ruby/data.avr file hanging around

I'm interested in performing some simple performance tests on EC2.  I
was thinking of using py_stress and Cassandra deployed on 3 servers with
one separate machine to run py_stress.

Are there any particular configuration settings I should use?  I was
planning on changing the JVM heap size to reflect the Large Instances
we're using.

Thanks!

Cheers,
Chris Dean

Hello,

Are the currently checked in functional tests working? The instructions
for
running them (http://wiki.apache.org/cassandra/HowToContribute) are not
working -- nosetests returns all failures -- and the init.py file does not
exist.

Thanks,
Marty