14 Matching Annotations
  1. Dec 2022
  2. Oct 2022
  3. May 2021
  4. Feb 2021
  5. May 2020
  6. Mar 2020
    1. The more data you send with each comment check, the better chance Akismet has of avoiding missed spam and false positives.

      They avoid saying "false negatives" and call it "missed spam" instead.... okay.

  7. Nov 2019
    1. you probably referred to the positive case where no one overrides anything and so the property returns true, so no need to process further because it is really an automation. Yes, this is true. I just hope that it does not make websites skip the checks if this returns false.
    1. I could mistakenly set onClick of the button to this.tgogle instead of this.toggle. My test continues to work, but my component is broken.
    2. So finally I'm coming out with it and explaining why I never use shallow rendering and why I think nobody else should either. Here's my main assertion:With shallow rendering, I can refactor my component's implementation and my tests break. With shallow rendering, I can break my application and my tests say everything's still working.This is highly concerning to me because not only does it make testing frustrating, but it also lulls you into a false sense of security. The reason I write tests is to be confident that my application works and there are far better ways to do that than shallow rendering.
    1. May not fail when you break application code. False positives
    2. This is called a false positive. It means that we didn't get a test failure, but we should have

      No, this is a false negative. We didn't get a test failure (that is, there is a lack of the condition (test failure)), when the condition (test failure) should have been present.

      Read https://en.wikipedia.org/wiki/False_positives_and_false_negatives

    3. Why is testing implementation details bad?There are two distinct reasons that it's important to avoid testing implementation details. Tests which test implementation details:Can break when you refactor application code. False negativesMay not fail when you break application code. False positives
    1. Using expect { }.not_to raise_error(SpecificErrorClass) risks false positives, as literally any other error would cause the expectation to pass, including those raised by Ruby (e.g. NoMethodError, NameError, and ArgumentError)

      Actually, those would be false negatives: the absence of a test failure when it should be there.

      https://en.wikipedia.org/wiki/False_positives_and_false_negatives