• (disco) in reply to Gaska
    Gaska:
    None of the above is possible if you can't modify the product.

    Sure it does. You just have to figure out a way to work around it.

    I mean...do you just throw your arms up in the air if you come across a 3rd party bug that you can't fix?

  • (disco) in reply to boomzilla
    boomzilla:
    Sure it does. You just have to figure out a way to work around it.
    Workaround != fix. And if you insist it is a fix I will kill you for the good of humanity. Software is fragile enough as it is.
    boomzilla:
    I mean...do you just throw your arms up in the air if you come across a 3rd party bug that you can't fix?
    That's exactly what I do. I report a bug and just stop using the bugged feature until it's fixed.
  • (disco) in reply to Gaska
    Gaska:
    Workaround != fix. And if you insist it is a fix I will kill you for the good of humanity. Software is fragile enough as it is.

    But for your code, that's the fix.

  • (disco) in reply to boomzilla
    boomzilla:
    But for your code, that's the fix.
    No it is not. I'm still unable to use the broken feature. No amounts of duct tape and abstraction will change the fact the feature is broken.

    Example: with GMock, Google's supplement for GTest, Google's UT framework for C++, having mock return shared pointer causes crash on test end. It's old and very deep bug they haven't fixed for at least two years, and there's no workaround other than not returning shared pointers (which our real code heavily depends on). We learned to use custom-tailored stubs for such cases and it kinda sorta works, but still.

  • (disco) in reply to Gaska

    OK, now you're just being obtuse.

    Sure, if the bug is that stuff crashes, you don't use it at all. Even so, having an automated test of this tells you when something like this happens the next time you have to upgrade that component.

  • (disco) in reply to boomzilla

    Let's say you have a point. Because in reality, it's unlikely to encounter a bug that was fixed some versions ago but has returned. In development, it happens all the time. But in release quality products it's unlikely.

    Also, the original discussion was about testing Adobe Dreamweaver CS3 - a giant window application, not some library. Do you realize how hard it is to write unit tests for window applications? Compared to, for example, remembering what not to do?

  • (disco) in reply to Gaska
    Gaska:
    Let's say you have a point. Because in reality, it's unlikely to encounter a bug that was fixed some versions ago but has returned. In development, it happens all the time.

    But you definitely might get a new bug that fails an old test.

    Gaska:
    But in release quality products it's unlikely.

    Right, because you're testing!

    Gaska:
    Also, the original discussion was about testing Adobe Dreamweaver CS3

    Yeah, I don't really care about the original discussion in this discussion.

  • (disco) in reply to boomzilla
    boomzilla:
    But you definitely might get a new bug that fails an old test.
    It might indicate that your test sucks. Because automated tests aren't only about *if* something's broken, but also *where*.
    boomzilla:
    Right, because you're testing!
    No, it's not because *I'M* testing. It's because *THEY'RE* testing.
    boomzilla:
    Yeah, I don't really care about the original discussion in this discussion.
    I do. Because half of what I said doesn't apply to libraries.
  • (disco) in reply to Gaska
    Gaska:
    It might indicate that your test sucks. Because automated tests aren't only about if something's broken, but also where.

    TDEMSYR

    Gaska:
    I do. Because half of what I said doesn't apply to libraries.

    Goddamnit, THAT'S WHAT WE'VE BEEN TALKING ABOUT.

  • (disco) in reply to boomzilla
    boomzilla:
    TDEMSYR
    If you say so.
    boomzilla:
    Goddamnit, THAT'S WHAT WE'VE BEEN TALKING ABOUT.
    Oh? I thought we were talking first about apps exclusively and then about general case.
  • (disco)

    If you're testing a product that you depend on, that is what I'd call a conformance test. You expect an external program or library to behave in a certain way. You test to ensure this behaviour stays the same, either with new versions of the external product, or with new builds of your own product (which may use slightly different parameters).

  • (disco) in reply to Gaska

    All of those things you said are possible, where "correct" and "fix" are substituted with "report" and "workaround".

    Automated testing has the same goal as any other form of testing: Increasing confidence. It doesn't matter if it's your own software or some 3rd party software you depend on, if you don't have confidence in it you can't have confidence in your end product.

  • (disco) in reply to Gaska
    Gaska:
    Also, the original discussion was about testing Adobe Dreamweaver CS3 - a giant window application, not some library. Do you realize how hard it is to write unit tests for window applications? Compared to, for example, remembering what not to do?

    This is an important point. I said unit testing is only worthwhile when the value of the increased confidence is higher than the cost of implementing the tests. Sometimes it's just not worth it, when the software under test is tightly coupled or has complex dependencies for example. I didn't say "100% automated test coverage" at any point, because that would be insane. What I did say is that 1st or 3rd party makes no difference.

  • (disco) in reply to Gaska
    Gaska:
    Because in reality, it's unlikely to encounter a bug that was fixed some versions ago but has returned. In development, it happens all the time. But in release quality products it's unlikely.

    Not true. It is rather likely in Discourse, and it's release quality. Jeff says so. Wow, it was hard to keep a straight face while typing that.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    Not true. It is rather likely in Discourse, and it's release quality. Jeff says so. <small><small><small>Wow, it was hard to keep a straight face while typing that.

    There's an emoticon for that. :smirk:

  • (disco) in reply to another_sam
    another_sam:
    I said unit testing is only worthwhile when the value of the increased confidence is higher than the cost of implementing the tests.
    You said something totally different - that unit testing is worthwhile **because** the value of the increased confidence and so on. Post #77. Disregard that. I misread your post. Still, I felt like you're trying to say it's worthwhile to write a test that runs DW, opens 8K file and ensures it doesn't crash - which it isn't.
    another_sam:
    I didn't say "100% automated test coverage" at any point, because that would be insane.
    With 1st party software it's perfectly reasonable code - except for "never should it ever" conditions like crazy sanity-checks that only fail if memory is corrupted or something, and for bugs in coverage measuring software (gcov for example frequently marks closing brackets in our C++ code as uncovered lines).
    HardwareGeek:
    Not true. It is rather likely in Discourse, and it's release quality. Jeff says so.
    It happened, yes. But it's unlikely to encounter such a piece of shit as Discourse.
  • (disco) in reply to another_sam
    Gaska:
    You said something totally different - that unit testing is worthwhile because the value of the increased confidence and so on. Post #77.
    Do you even read what you read? Post 77:
    another_sam:
    Unit testing is for increasing confidence, and that's just as valid for 3rd party software as it is for 1st party. Unit test anywhere the increased confidence provides more value than the cost of writing the tests.
  • (disco) in reply to aliceif
    aliceif:
    Do you even read what you read?Post 77:
    I tried to make ninja edit but I failed.

    Filed under: Hanzo edit done right

  • (disco) in reply to HardwareGeek

    No, the first comma is optional too. Or are you saying that the following is not well-formed?

    Giraffes live in warm climates and polar bears live in cold ones since their fur keeps them warm.

    I agree that both commas help avoid ambiguity, but that doesn't make either of them grammatically necessary. The original sentence is complicated but standard.

  • SomeName (unregistered) in reply to Patrick_Schluter

    Relying on undefined behaviour is the source of the bug... Using +1 is just a workaround that might break tomorrow.

Leave a comment on “The 8K Bug”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article