Bug 144504 - JDT Core model JUnit tests fail when ordering of methods reversed
Summary: JDT Core model JUnit tests fail when ordering of methods reversed
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2.1   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 142528
  Show dependency tree
 
Reported: 2006-05-30 13:53 EDT by Sonia Dimitrov CLA
Modified: 2006-09-11 13:49 EDT (History)
5 users (show)

See Also:


Attachments
JUnit results (3.2RC6) (1.18 MB, text/html)
2006-05-30 13:53 EDT, Sonia Dimitrov CLA
no flags Details
Proposed patch (1.16 MB, patch)
2006-05-31 10:56 EDT, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sonia Dimitrov CLA 2006-05-30 13:53:02 EDT
Per bug 142528 comment 3, this report is being open to indicate that there are
failures in the JDT Core model tests when the test methods are added in reverse order
(see bug 142528 comment 1).

Attachment to follow with results.
Comment 1 Sonia Dimitrov CLA 2006-05-30 13:53:51 EDT
Created attachment 42991 [details]
JUnit results (3.2RC6)
Comment 2 Olivier Thomann CLA 2006-05-30 15:21:33 EDT
I'll see what I can do.
Comment 3 Olivier Thomann CLA 2006-05-30 21:11:02 EDT
The order that we get with the Sun VM seems to be the order in which the methods are defined.
So we either fix the creation of the tests' list to get a specific order (alphabetic order, ...) or we specify explicitly the order of the tests for the test suites that are failing with JRockit VM.
Comment 4 Philipe Mulet CLA 2006-05-31 06:20:53 EDT
It would be good to understand the nature of the problem. I would fix the tests to be order independant.

Comment 5 Philipe Mulet CLA 2006-05-31 06:21:55 EDT
also cc'ing Frederic our search test owner
Comment 6 Olivier Thomann CLA 2006-05-31 08:31:40 EDT
The nature of the problem is simple. Some tests are expecting to be run in a specific order. The first one sets some working copies and the other ones are using the same working copies.
Unfortunately the order is VM dependant. So on Sun VM, the order seems to be the declaration order. But this is not garantee to be true. So the test suite that are based on this assumption should specify explicitely the order of the tests.
Comment 7 Frederic Fusier CLA 2006-05-31 09:06:58 EDT
I will fix problems in JavaSearchBugsTests and also all potential ones which use AbstractJavaModelTests.discard field...

David, there are also some problems with completion tests, please have a look at them (except in JavadocFieldCompletionModelTest), thanks
Comment 8 Frederic Fusier CLA 2006-05-31 10:56:20 EDT
Created attachment 43103 [details]
Proposed patch

Fix all tests to be independant from execution order in:
  - JavaSearchBugTests
  - JavadocFieldCompletionTests
  - ASTConverterTest2
  - ASTConverterTestAST3_2

Sort tests while suite execution in:
  - CompletionTests: should be changed to be independant from exec order
                     post 3.2
  - CreationMemberTests
Comment 9 Frederic Fusier CLA 2006-05-31 11:07:28 EDT
Patch released in HEAD.
Comment 10 Frederic Fusier CLA 2006-05-31 13:37:15 EDT
Patch released in TARGET_321 branch
Comment 11 Olivier Thomann CLA 2006-06-02 16:01:59 EDT
Verified with I20060602-1317 for RC7 by running the Model tests using the JRockit VM.
Comment 12 Frederic Fusier CLA 2006-06-12 06:02:29 EDT
Reopen to verify it in R3_2_maintenance stream...
Comment 13 Frederic Fusier CLA 2006-06-12 06:03:39 EDT
Released for 3.2.1 (TARGET_321 was branched before 3.2 RC7...)
Comment 14 David Audel CLA 2006-07-05 10:21:31 EDT
I changed CompletionTests to be independant from exec order in 3.3.
Comment 15 Frederic Fusier CLA 2006-08-03 07:20:02 EDT
Released for 3.3 M1
Comment 16 Frederic Fusier CLA 2006-08-04 12:09:18 EDT
Verified for 3.3 M1 using build I20060804-0010.
Comment 17 Olivier Thomann CLA 2006-09-11 13:49:58 EDT
Verified for 3.2.1 using build M20060908-1655.