Unit test failing after migrating to Xcode 10












0















I have a suite of unit tests for my app that were running fine on Xcode 9.4.1. After upgrading to 10.1, I'm experiencing a failure around asserting that a weak reference var is nil after setting it's respective var it points at to nil. Any ideas why this will fail now that I've upgraded? Other tests follow this pattern, but aren't failing.
EDIT: here's the new, non-failing code. just needed to init the button in the performSetup() autoreleasepool{}...



var button: CustomButton!
var buttonSize: CGSize = CGSize(width: 0, height: 0)

override func performSetup(file: StaticString = #file, line: UInt = #line) {
super.performSetup(file: file, line: line)


autoreleasepool {
if button == nil {
button = CustomButton()
buttonSize = button.designDataMinimumButtonSize()
}
addToAndCenterWithinHostView(subview: button)
}
}

override func performTeardown(file: StaticString = #file, line: UInt = #line) {
// Verify that no strong reference cycles keep the test objects alive.
weak var weakComponent = button

autoreleasepool {
button.removeFromSuperview()
button = nil

super.performTeardown(file: file, line: line)
}

// This assertion tests for strong reference cycles in the tested code.
// However, if the assertion fails, it may be because the test did not
// wait for a closure that was asynchronously dispatched to finish. In
// that case, there is not a bug in the tested code and the test should
// be modified to wait for the dispatched closure to finish.
XCTAssertNil(weakComponent, "Expected no strong references to 'button' to exist.")
}









share|improve this question





























    0















    I have a suite of unit tests for my app that were running fine on Xcode 9.4.1. After upgrading to 10.1, I'm experiencing a failure around asserting that a weak reference var is nil after setting it's respective var it points at to nil. Any ideas why this will fail now that I've upgraded? Other tests follow this pattern, but aren't failing.
    EDIT: here's the new, non-failing code. just needed to init the button in the performSetup() autoreleasepool{}...



    var button: CustomButton!
    var buttonSize: CGSize = CGSize(width: 0, height: 0)

    override func performSetup(file: StaticString = #file, line: UInt = #line) {
    super.performSetup(file: file, line: line)


    autoreleasepool {
    if button == nil {
    button = CustomButton()
    buttonSize = button.designDataMinimumButtonSize()
    }
    addToAndCenterWithinHostView(subview: button)
    }
    }

    override func performTeardown(file: StaticString = #file, line: UInt = #line) {
    // Verify that no strong reference cycles keep the test objects alive.
    weak var weakComponent = button

    autoreleasepool {
    button.removeFromSuperview()
    button = nil

    super.performTeardown(file: file, line: line)
    }

    // This assertion tests for strong reference cycles in the tested code.
    // However, if the assertion fails, it may be because the test did not
    // wait for a closure that was asynchronously dispatched to finish. In
    // that case, there is not a bug in the tested code and the test should
    // be modified to wait for the dispatched closure to finish.
    XCTAssertNil(weakComponent, "Expected no strong references to 'button' to exist.")
    }









    share|improve this question



























      0












      0








      0








      I have a suite of unit tests for my app that were running fine on Xcode 9.4.1. After upgrading to 10.1, I'm experiencing a failure around asserting that a weak reference var is nil after setting it's respective var it points at to nil. Any ideas why this will fail now that I've upgraded? Other tests follow this pattern, but aren't failing.
      EDIT: here's the new, non-failing code. just needed to init the button in the performSetup() autoreleasepool{}...



      var button: CustomButton!
      var buttonSize: CGSize = CGSize(width: 0, height: 0)

      override func performSetup(file: StaticString = #file, line: UInt = #line) {
      super.performSetup(file: file, line: line)


      autoreleasepool {
      if button == nil {
      button = CustomButton()
      buttonSize = button.designDataMinimumButtonSize()
      }
      addToAndCenterWithinHostView(subview: button)
      }
      }

      override func performTeardown(file: StaticString = #file, line: UInt = #line) {
      // Verify that no strong reference cycles keep the test objects alive.
      weak var weakComponent = button

      autoreleasepool {
      button.removeFromSuperview()
      button = nil

      super.performTeardown(file: file, line: line)
      }

      // This assertion tests for strong reference cycles in the tested code.
      // However, if the assertion fails, it may be because the test did not
      // wait for a closure that was asynchronously dispatched to finish. In
      // that case, there is not a bug in the tested code and the test should
      // be modified to wait for the dispatched closure to finish.
      XCTAssertNil(weakComponent, "Expected no strong references to 'button' to exist.")
      }









      share|improve this question
















      I have a suite of unit tests for my app that were running fine on Xcode 9.4.1. After upgrading to 10.1, I'm experiencing a failure around asserting that a weak reference var is nil after setting it's respective var it points at to nil. Any ideas why this will fail now that I've upgraded? Other tests follow this pattern, but aren't failing.
      EDIT: here's the new, non-failing code. just needed to init the button in the performSetup() autoreleasepool{}...



      var button: CustomButton!
      var buttonSize: CGSize = CGSize(width: 0, height: 0)

      override func performSetup(file: StaticString = #file, line: UInt = #line) {
      super.performSetup(file: file, line: line)


      autoreleasepool {
      if button == nil {
      button = CustomButton()
      buttonSize = button.designDataMinimumButtonSize()
      }
      addToAndCenterWithinHostView(subview: button)
      }
      }

      override func performTeardown(file: StaticString = #file, line: UInt = #line) {
      // Verify that no strong reference cycles keep the test objects alive.
      weak var weakComponent = button

      autoreleasepool {
      button.removeFromSuperview()
      button = nil

      super.performTeardown(file: file, line: line)
      }

      // This assertion tests for strong reference cycles in the tested code.
      // However, if the assertion fails, it may be because the test did not
      // wait for a closure that was asynchronously dispatched to finish. In
      // that case, there is not a bug in the tested code and the test should
      // be modified to wait for the dispatched closure to finish.
      XCTAssertNil(weakComponent, "Expected no strong references to 'button' to exist.")
      }






      ios swift xcode






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 28 '18 at 21:27







      Noah

















      asked Nov 21 '18 at 23:46









      NoahNoah

      26118




      26118
























          1 Answer
          1






          active

          oldest

          votes


















          0














          Solved this by putting the initialization of the button in the performSetup() method's autoreleasepool{}. Answer edited with new code...






          share|improve this answer





















          • 1





            Please show the new code.

            – matt
            Dec 28 '18 at 20:39











          • Ok, I've edited the answer

            – Noah
            Dec 28 '18 at 21:28











          • No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

            – matt
            Dec 28 '18 at 21:37











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422017%2funit-test-failing-after-migrating-to-xcode-10%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          Solved this by putting the initialization of the button in the performSetup() method's autoreleasepool{}. Answer edited with new code...






          share|improve this answer





















          • 1





            Please show the new code.

            – matt
            Dec 28 '18 at 20:39











          • Ok, I've edited the answer

            – Noah
            Dec 28 '18 at 21:28











          • No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

            – matt
            Dec 28 '18 at 21:37
















          0














          Solved this by putting the initialization of the button in the performSetup() method's autoreleasepool{}. Answer edited with new code...






          share|improve this answer





















          • 1





            Please show the new code.

            – matt
            Dec 28 '18 at 20:39











          • Ok, I've edited the answer

            – Noah
            Dec 28 '18 at 21:28











          • No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

            – matt
            Dec 28 '18 at 21:37














          0












          0








          0







          Solved this by putting the initialization of the button in the performSetup() method's autoreleasepool{}. Answer edited with new code...






          share|improve this answer















          Solved this by putting the initialization of the button in the performSetup() method's autoreleasepool{}. Answer edited with new code...







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Dec 28 '18 at 21:27

























          answered Dec 28 '18 at 20:20









          NoahNoah

          26118




          26118








          • 1





            Please show the new code.

            – matt
            Dec 28 '18 at 20:39











          • Ok, I've edited the answer

            – Noah
            Dec 28 '18 at 21:28











          • No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

            – matt
            Dec 28 '18 at 21:37














          • 1





            Please show the new code.

            – matt
            Dec 28 '18 at 20:39











          • Ok, I've edited the answer

            – Noah
            Dec 28 '18 at 21:28











          • No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

            – matt
            Dec 28 '18 at 21:37








          1




          1





          Please show the new code.

          – matt
          Dec 28 '18 at 20:39





          Please show the new code.

          – matt
          Dec 28 '18 at 20:39













          Ok, I've edited the answer

          – Noah
          Dec 28 '18 at 21:28





          Ok, I've edited the answer

          – Noah
          Dec 28 '18 at 21:28













          No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

          – matt
          Dec 28 '18 at 21:37





          No, you edited the question. Show the old nonworking code in the question and the fixed code in the answer. Thanks!

          – matt
          Dec 28 '18 at 21:37


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422017%2funit-test-failing-after-migrating-to-xcode-10%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Costa Masnaga

          Fotorealismo

          Sidney Franklin