Commits on Oct 3, 2023

1. Prepare for 2023.3: Move tests using MyMockApplication to unittests …

   If I understand this correctly, the problem existed from the beginning,
   it has been revealed by this change:
   JetBrains/intellij-community@c973850#diff-4497b4c4afdd25574053db8b6de01a43669c1b3200a5d4d31d14da002614e400L956
   
   In the old IntelliJ versions, if I understand correctly, the tests were successful because
   1. Some of the intergration tests were spawning the original non-mock application
   2. The non-mock application was scheduling the DaemonCodeAnalyzerImpl's runUpdate
   3. The non-mock test has finished
   4. Then the mock-based tests has started
   5. A mock-based started and installed MyMockApplication to ApplicationManager
   6. The DaemonCodeAnalyzerImpl's job was still running and it scheduled ApplicationManager.getInstance().invokeLater()
   7. As MyMockApplication was already installed, it handled the invokeLater call
   8. DaemonCodeAnalyzerImpl's runUpdate called ApplicationManager.getApplication().assertIsDispatchThread()
   9. But in MockApplication, the assertIsDispatchThread() method is implemented as empty, so nothing was crashing
   
   Since the commit c973850dd, the dispatch thread assertion is not delegated to the Application any more,
   but it is done by ThreadingAssertions.assertEventDispatchThread, which is not implemented in MockApplicaion,
   hence it really checks whether the thread is EDT.
   
   For this reason, we would like to separate all tests relying on MyMockApplication from the ones relying on
   the real Application. This would not solve the race fully, but at least it wouldn't lead to a case where
   a task scheduled by real Application is run by MockApplication

   

   tpasternak committed Oct 3, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 398925e
   • Browse repository at this point

   Copy the full SHA

   398925e View commit details

   Browse the repository at this point in the history