• (cs)

    I would have been frist but I had to run the tests first.

  • Jumentum (unregistered)

    So sleepy! Test need coffee!!

  • gnasher729 (unregistered)

    In the last ten years, I haven't done any performance optimisation by doing something particularly clever. I have done lots of performance improvements by replacing really stupid code, including one bit of code that opened and inspected O (n^3) files if a particular directory contained n files.

  • sehe (unregistered) in reply to gnasher729

    Did it open O(2*m) files (I didn't know that O(x) was an integral unit, by the way) if a particular directory contained k files?

  • Sebastian Ramadan (unregistered)

    Is that a measurement of best, average or worst case constant fopens?

  • TroelsL (unregistered)

    That is just stupid. Clearly, they should save the current time before the try block, and Assert that the correct amount of time has passed after the test.

    Otherwise, it just makes no sense at all.

  • Craig (unregistered)

    Just trying to figure out what the original developer was trying to achieve with this is a tough one.

    The only reason I can come up with is that they inserted a manual pause so the dev could attach a debugger of some kind and snoop around the codebase to determine the state of the application?

    Ignoring that it's not really the right thing to do in a unit test, there are better ways to get the same result.

  • Mike (unregistered)

    "Motumbo noticed previous builds were taking over two hours. This wasn't necessarily a problem"

    And there's TRWTF right there

  • Jeroen (unregistered) in reply to Craig

    I once wrote something like that... but it only slept for a second, not hours. I was working on a BSP which offered (among a lot of other stuff) some time functions.

    My test would:

    • retrieve an internal CPU counter running at its clock speed.
    • sleep for 1 second using BSP timing functions
    • retrive counter again.
    • calculate difference between counters and compare with clock speed.

    The difference between the counters has to be the external clock frequency (with a reasonable error range). This way I could test wether the seconds reported by the BSP were really seconds.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    tdwtfthread.Sleep(120000);

    Now nobody can post in this thread for two minutes.

  • tim (unregistered)

    but why specifically sleep for 8 x 812 seconds? you'd normally expect it to be a multiple of minutes or something

  • (cs)

    // TODO Auto-generated interesting comment

  • (cs) in reply to Mike
    Mike:
    "Motumbo noticed previous builds were taking over two hours. This wasn't necessarily a problem"

    And there's TRWTF right there

    If the build is doing something necessary, like compiling a very large codebase, then taking over two hours isn't a WTF, especially if we are talking something like template-heavy C++. If there are lots of automated unit tests to run in a "make unittest" type of build (using the results of a compilation build, for example), then this might (for a very large codebase) take a couple of hours.

    So no, the mere fact that a test build takes over two hours is not a WTF, nor is considering such a thing "not a problem" a WTF. If the test code sleeps for an hour and 48 minutes, that's a problem, and probably a WTF as well. In fact, there's no "probably" about it...

  • anonymous (unregistered)

    This kind of stupidity still baffles me, after so many years doing development. That's a good thing, I guess. Means I'm still retaining my sanity.

  • Aberzdf (unregistered)

    Quartz is used as a cronjob equivalent in java. I suspect this was originally intended to test if quartz was doing a cronjob that would only happen every X minutes.

    I suspect that was the intention... now there are still a number of issues with how they tried to do this, but at least it explains the sleep.

  • DB (unregistered)

    This is not necessarily a WTF. The purpose of this test is obviously to run the application for an extended time and then print the stack trace to search for infinite loops or memory leakage.

  • Sindri Traustason (unregistered) in reply to Aberzdf
    Aberzdf:
    Quartz is used as a cronjob equivalent in java. I suspect this was originally intended to test if quartz was doing a cronjob that would only happen every X minutes.

    Well spotted with the Quartz reference.

    Still doesn't explain the 8 times 812 seconds. How did they come up with that? Don't these people know that all time values must be some multiples of 2, 3 and 10!?

  • anon (unregistered) in reply to Sindri Traustason

    It's simple really...

    http://sacredscribesangelnumbers.blogspot.no/2011/12/angel-number-812.html

    "Number 812 is a compilation of the attributes and vibrations of the numbers 8, 1 and 2. Number 8 adds its energies of personal authority, manifesting wealth and abundance, authority, giving and receiving, inner-wisdom, material success and Karma - the Spiritual Law of Cause and Effect. Number 1 adds its qualities of the ‘new’, intuition and insight, activity and attainment, motivation and fulfilment. Number 2 brings its attributes of faith and trust, duality and balance, Divine life mission and purpose, insight, positivity and encouragement"

  • cowardly man (unregistered)

    I heard a story about someone doing this where I work YEARS ago. They basically wanted a viable excuse to go get a snack.

    "Why aren't you doing testing?" "The tests are running, they take about 15 minutes."

  • Anon (unregistered) in reply to cowardly man
    cowardly man:
    I heard a story about someone doing this where I work YEARS ago. They basically wanted a viable excuse to go get a snack.

    "Why aren't you doing testing?" "The tests are running, they take about 15 minutes."

    Sounds entirely plausible. Perhaps they needed an extra long lunch break. Or maybe this:

    [image]
  • hurley (unregistered) in reply to tim
    tim:
    but why specifically sleep for 8 x 812 seconds? you'd normally expect it to be a multiple of minutes or something

    Because 8x812 seconds is 108 minutes and 16 seconds. 16 is one of the numbers. 108 is the sum of the numbers.

    4 8 15 16 23 42

    THE NUMBERS ARE BAD!

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to hurley
    hurley:
    tim:
    but why specifically sleep for 8 x 812 seconds? you'd normally expect it to be a multiple of minutes or something
    Because 8x812 seconds is 108 minutes and 16 seconds. 16 is one of the numbers. 108 is the sum of the numbers.

    4 8 15 16 23 42

    THE NUMBERS ARE BAD!

    Maybe he was trying to make a 2048 combo?

  • (cs) in reply to Aberzdf
    Aberzdf:
    Quartz is used as a cronjob equivalent in java. I suspect this was originally intended to test if quartz was doing a cronjob that would only happen every X minutes.

    I suspect that was the intention... now there are still a number of issues with how they tried to do this, but at least it explains the sleep.

    Yeah, they're testing to see if something happens to the task in that period of time. I'm going to guess there was a problem with the task being terminated for some reason.

  • hurley (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    hurley:
    tim:
    but why specifically sleep for 8 x 812 seconds? you'd normally expect it to be a multiple of minutes or something
    Because 8x812 seconds is 108 minutes and 16 seconds. 16 is one of the numbers. 108 is the sum of the numbers.

    4 8 15 16 23 42

    THE NUMBERS ARE BAD!

    Maybe he was trying to make a 2048 combo?

    Curse you! I was happy to chalk that one up to Randall being weird and ignore it, but no, you had to make that connection, I had to Google 2048 game, and now I'm irrationally happy that I made a 256.

  • (cs) in reply to gnasher729
    gnasher729:
    In the last ten years, I haven't done any performance optimisation by doing something particularly clever. I have done _lots_ of performance improvements by replacing really stupid code, including one bit of code that opened and inspected O (n^3) files if a particular directory contained n files.

    I give up: where did it even find that many files?

  • (cs) in reply to hurley

    [quote user="hurley"][quote user="¯(°_o)/¯ I DUNNO LOL"][quote user="hurley"]]Maybe he was trying to make a 2048 combo?[/quote]

    Curse you! I was happy to chalk that one up to Randall being weird and ignore it, but no, you had to make that connection, I had to Google 2048 game, and now I'm irrationally happy that I made a 256.[/quote]

    Well there's your problem in a nut(c-)shell: 256 isn't irrational!

  • Mason Wheeler (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Mike:
    "Motumbo noticed previous builds were taking over two hours. This wasn't necessarily a problem"

    And there's TRWTF right there

    If the build is doing something necessary, like compiling a very large codebase, then taking over two hours isn't a WTF, especially if we are talking something like template-heavy C++.

    And there's TRWTF right there.

  • Thus spake the troll! (unregistered)

    Taking over 2 hours for a build is a silly idea. All builds should be compiled under 10 minutes. If it takes anything longer than 10 minutes, you need to refactor your code.

  • Anonymous coward (unregistered)

    Damnit TDWTF stop giving away all my tricks!

  • gnasher729 (unregistered) in reply to Sebastian Ramadan
    Sebastian Ramadan:
    Is that a measurement of best, average or worst case constant fopens?

    Average about n^3 / 6 opens and reads for n files in a certain directory. Now obviously if you do this, the OS will do wonders for you caching things, but still... I can't remember exactly how fast it was, but when I tried the code by adding files it quickly went to a noticeable delay, to an annoying delay, to thinking that the app was stuck.

  • gnasher729 (unregistered) in reply to cellocgw
    cellocgw:
    gnasher729:
    In the last ten years, I haven't done any performance optimisation by doing something particularly clever. I have done _lots_ of performance improvements by replacing really stupid code, including one bit of code that opened and inspected O (n^3) files if a particular directory contained n files.

    I give up: where did it even find that many files?

    It opened and read the same files over and over again.

    A directory could contain files that the app was interested in, and files that it wasn't interested in.

    There was a method "getNthFile" which returned the n-th "interesting" file, by opening files one after the other, checking if they were interesting or not, until the n-th interesting file was found. Assuming no uninteresting file, this method took O (n).

    Then a method "getNFiles" which returned an array of the first n interesting files. By calling "getNthFile" with i = 1 to n. This method took O (n^2).

    Then a method which increased the number of files to display from 1 to n. Each time "getNFiles" was called. O (n^3).

  • (cs)

    Obviously, it was just trying to emulate how slow Java would be in a production environment.

  • Scourge of programmers. (unregistered) in reply to chubertdev
    chubertdev:
    Obviously, it was just trying to emulate how slow Java would be in a production environment.

    Java != Slow!

  • anonymous (unregistered) in reply to Scourge of programmers.
    Scourge of programmers.:
    chubertdev:
    Obviously, it was just trying to emulate how slow Java would be in a production environment.

    Java != Slow!

    Virtually every Java application I've ever seen was slow as shit but still managed to avoid repainting the window when it was being resized or dragged around the screen. Because obviously it had so much else to do. God forbid that it should waste 3 CPU cycles repainting the screen until you're absolutely done moving it or resizing it.

  • sheep (unregistered) in reply to tim
    tim:
    but why specifically sleep for 8 x 812 seconds? you'd normally expect it to be a multiple of minutes or something
    Shit, I got my math wrong. That was meant to be 10 * 600.

    Cheers for that!

  • (cs) in reply to Anon
    Anon:
    cowardly man:
    I heard a story about someone doing this where I work YEARS ago. They basically wanted a viable excuse to go get a snack.

    "Why aren't you doing testing?" "The tests are running, they take about 15 minutes."

    Sounds entirely plausible. Perhaps they needed an extra long lunch break. Or maybe this:

    [image]

    Years ago at one company, it took about an hour to do a full compile of all the code. I made 3 pm more or less a standard time to do a full compile so that I could leave the office for a little while.

    It wasn't so much that I had anything in particular to do as that I wanted to get out of the office at that time of day. My fellow cow-orkers had a thing for microwave popcorn at about 3 pm every day. I was just trying to escape the nauseating smell and give it time to air out a bit before I returned.

  • aaaadrt ;jio (unregistered) in reply to Thus spake the troll!
    Thus spake the troll!:
    Taking over 2 hours for a build is a silly idea. All builds should be compiled under 10 minutes. If it takes anything longer than 10 minutes, you need to refactor your code.
    Nonsense, it's compile time should be inversely proportionate to the exponent of its runtime
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to eric76
    eric76:
    It wasn't so much that I had anything in particular to do as that I wanted to get out of the office at that time of day. My fellow cow-orkers had a thing for microwave popcorn at about 3 pm every day. I was just trying to escape the nauseating smell and give it time to air out a bit before I returned.
    Didn't you used to do work with lasers back in the '80s?
  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    eric76:
    It wasn't so much that I had anything in particular to do as that I wanted to get out of the office at that time of day. My fellow cow-orkers had a thing for microwave popcorn at about 3 pm every day. I was just trying to escape the nauseating smell and give it time to air out a bit before I returned.
    Didn't you used to do work with lasers back in the '80s?

    Wasn't that myth busted?

  • Norman Diamond (unregistered) in reply to hurley
    hurley:
    ¯\(°_o)/¯ I DUNNO LOL:
    Maybe he was trying to make a 2048 combo?
    Curse you! I was happy to chalk that one up to Randall being weird and ignore it, but no, you had to make that connection, I had to Google 2048 game, and now I'm irrationally happy that I made a 256.
    I'd be irrationally happy if I made a sqrt(2).
  • (cs)

    :rimshot:

  • (cs) in reply to gnasher729
    gnasher729:
    It opened and read the same files over and over again.
    A certain game by a well-known game company reads each of its resource files many times during start-up. If it happens to encounter an invalid resource file (from a previous version of the game), does it realize that it is invalid and ignore it? No, it retries, as though it will be magically replaced with a valid file the next time it tries to read it. I've seen it access the same invalid file >100k times.
  • testQuartz (unregistered) in reply to chubertdev
    chubertdev:
    :rimshot:
    Huh? What? Loud noise? I was sleeping! Why did you wake me from my sleep?
  • (cs)

    Oh, for the days when compiles took 30 minutes...

  • Elim (unregistered) in reply to Coyne
    Coyne:
    Oh, for the days when compiles took 30 minutes...
    They still can! Just run your builds on an EC2 micro instance when you're feeling nostalgic. With CPU throttling, you can compile like it's 1996.
  • (cs) in reply to Coyne
    Coyne:
    Oh, for the days when compiles took 30 minutes...

    Ever heard of SLOBOL?

  • (cs) in reply to chubertdev
    chubertdev:

    Wasn't that myth busted?

    They found that you can't explode a house by popping popcorn in it, but it is definitely possible to pop popcorn with a laser.

  • mar77i (unregistered)

    But if the tests don't take long enough, you have no way to tell if you did or didn't run the tests!

    So the suit dictated the programmers to do something that makes the tests take a bit of time... it probably should help the dev's memory to sit around and think about what he was doing or something down that road.

    WE HAVE ENTERPRISE SCALE SLOWNESS NOW... (madness ensues)

  • (cs) in reply to Aberzdf
    Aberzdf:
    Quartz is used as a cronjob equivalent in java. I suspect this was originally intended to test if quartz was doing a cronjob that would only happen every X minutes.

    I suspect that was the intention... now there are still a number of issues with how they tried to do this, but at least it explains the sleep.

    Yes; since the setup method is not shown, who knows what environment the test is running in. I'm guessing that the setup method starts an async process. Somehow (which escapes me) the async process could cause the launching thread to throw an exception, which is caught in the test.

    The test does not fail if the exception is thrown, though, which leads to a pretty useless test, since it will always appear to succeed.

  • anonymous (unregistered) in reply to DrPepper
    DrPepper:
    Aberzdf:
    Quartz is used as a cronjob equivalent in java. I suspect this was originally intended to test if quartz was doing a cronjob that would only happen every X minutes.

    I suspect that was the intention... now there are still a number of issues with how they tried to do this, but at least it explains the sleep.

    Yes; since the setup method is not shown, who knows what environment the test is running in. I'm guessing that the setup method starts an async process. Somehow (which escapes me) the async process could cause the launching thread to throw an exception, which is caught in the test.

    The test does not fail if the exception is thrown, though, which leads to a pretty useless test, since it will always appear to succeed.

    After stumbling around a bit in Google I think I've figured out what the purpose of that unit test was.

    Thread.sleep() will put the thread in a blocked waiting state. If another process or thread wants to shut down the thread (or ask that it resume immediately), Thread.sleep() will throw an InterruptedException. The code which called Thread.sleep() should catch this exception and come to a graceful halt. If it doesn't, the thread can't be stopped gracefully. So basically, on every call that will block the thread, you have to consider that the thread might receive a shutdown interrupt (and it can only receive a shutdown interrupt while it is blocked).

    Either the unit test was supposed to protect the thread from receiving an InterruptedException, or for some reason they just wanted to stress-test Thread.sleep() and "knew" that they needed to catch the InterruptedException without really knowing why.

    This is my non-Java-programmer interpretation of the glob of information provided here.

Leave a comment on “Test Driven Delay”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article