Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5559

onTestCaseStart event can fire multiple times in IoC Testing fixture

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Component/s: IoC Testing Framework
    • Labels:
      None

      Description

      As part of the FLUID-4929 fix we introduced an event intrinsic to an IoC Testing framework fixture, "onTestCaseStart", which allows the timing of component construction to be "caught" by the beginning of a fixture sequence - the typical use of this is via a createOnEvent: "onTestCaseStart" directive. An implementation bug allows this event to fire twice for the same sequence if the listener to initial firing synchronously causes control to pass to the final element of the sequence. This event was implemented lazily using two firing sites and guarded by a flag whose setting was mistimed.

      This arose during work on the preference editing framework - https://github.com/cindyli/prefsEditors/blob/GPII-1014/tests/adjusters/js/cursorSizePCPTests.js#L106-L107 held

      sequence: [{
      listener: "gpii.tests.cursorSizePCPTests.testDefault",
      priority: "last",
      event: "

      {cursorSizePCPTests cursorSizePCP}

      .events.afterRender"
      }, {
      func: "gpii.tests.cursorSizePCPTests.pressStepper",
      args: ["

      {cursorSizePCP}

      "]
      }]

      where the corresponding environment was defined as

      fluid.defaults("gpii.tests.cursorSizePCPTests", {
      gradeNames: ["fluid.test.testEnvironment", "autoInit"],
      components: {
      cursorSizePCP: {
      type: "gpii.adjuster.cursorSizePCP",
      container: ".gpiic-cursorSizePCP",
      createOnEvent: "

      {cursorSizePCPTester}

      .events.onTestCaseStart",

      the framework passes via its "makeBinder" directly from the listener to sequence point 0 to point 1, triggering the re-construction of the "cursorSizePCP" component before its first construction has finished. There's probably a strong case for introducing asynchrony between all transitions in these test case fixtures, since the behaviour of the framework on re-initiating construction or destruction during either construction or destruction is undefined. These conditions should also receive explicit diagnostics - although these wouldn't have done a much better job in trapping and explaining the current issue than the one we already have.

        Attachments

          Activity

            People

            Assignee:
            antranig Antranig Basman
            Reporter:
            antranig Antranig Basman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: