Bug 198956 - [test] FileServiceArchiveTest does not initialize properly
Summary: [test] FileServiceArchiveTest does not initialize properly
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 2.0.1   Edit
Assignee: Martin Oberhuber CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-06 12:38 EDT by Martin Oberhuber CLA
Modified: 2007-09-26 19:47 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-08-06 12:38:37 EDT
Trying to run FileServiceArchiveTest in my environment, half of the testcases fail with a NullPointerException while the others run OK.

I think that the setUp() code, which unconditionally waits for 500 msec, is not correct; it must wait until the InitRSEJob is complete.

See also bug 194802
Comment 1 Martin Oberhuber CLA 2007-08-06 13:01:17 EDT
Fixed the issue (and several others) with the following measures:

1. Added RSECoreTestCase.waitForRSEWorkspaceInit(), and call it in setUp().
   Since RSECoreTestCase is the base class for all RSE test cases, this is
   the right place to ensure the InitRSEJob has run.

2. In all derived classes, ensure that setUp() calls super.setUp() and
   tearDown calls super.tearDown()

3. For FileServiceArchiveTest, removed classBeenRunBefore and associated
   code which waited 500 msec. 

4. For Archive tests, moved setUp() and tearDown() from FileServiceArchiveTest
   to the parent class, FileServiceBaseTest. The protected instance variables
        fss, fs, localFss, tempDir
   are all decalred in FileServiceBaseTest, so the associated setUp / tearDown
   code should be in the same class -- or it would be very confusing.

5. Added "... throws Exception" to most new test cases, and removed unnecessary
   try..catch constructs. 
   The test cases had been written with lots of try..catch around it, but this
   is not the intention of unit tests. In a unit test, we do want exceptions
   to be thrown as early as possible, when anything is not as expected. The
   advantage of throwing exceptions early, is that in the JDT JUnit View, 
   we can navigate to the root of an exception right away (rather than just
   printing something to the console).

6. Replaced many
      assertTrue(x==null)
   by 
      assertNull(x)  / assertNotNull(x)
   since this is more readable and gives better output in case of failure.
   Replaced some System.out.println("x is null") by simply allowing it
   throw an exception.

7. In those tests where setUp() modified a system Preference, tearDown()
   now restores that Preference. This is important, because our unit tests
   can also be run inside the workspace of a running product. We must ensure
   that these workspace settings are not modified by the test.

8. In the Checked-in Launch:
     org.eclipse.rse.tests/teamConfig/RSE Combined Test Suite.launch
   added VM arguments:
     -ea -esa -Dcom.sun.management.jmxremote
   That way, the unit tests are run with Assertions enabled in the RSE Code
   where possible; and the Sun Management Console is enabled for debugging
   deadlocks, even if the tests are run without the debugger.


Fixes committed,
[198956][tests] Fix initialization of RSE Unit tests by waiting for InitRSEJob