• mike (unregistered)

    Unit test flamewar thread! Yay!

    Captcha: amet - amet a guy who wrote unit tests. He was stupid.

  • Some Jerk (unregistered) in reply to Ken B.
    Ken B.:
    ¿uʍop ǝpısdn sʇuǝɯɯoɔ ɹnoʎ ǝʇıɹʍ ʇsnɾ ʇou ʎɥʍ

    how the hell did you do that dude?

    captcha: genitus ... just don't scratch them at work

  • (cs) in reply to Some Jerk
    Some Jerk:
    Ken B.:
    ¿uʍop ǝpısdn sʇuǝɯɯoɔ ɹnoʎ ǝʇıɹʍ ʇsnɾ ʇou ʎɥʍ

    how the hell did you do that dude?

    captcha: genitus ... just don't scratch them at work

    Screw that, I am going to name my variables upside down from now on.

    public String plɹoʍollǝɥ;

    Holy Crap, Java accepted that!

  • swedish tard (unregistered) in reply to Some Jerk
    Some Jerk:
    Ken B.:
    ¿uʍop ǝpısdn sʇuǝɯɯoɔ ɹnoʎ ǝʇıɹʍ ʇsnɾ ʇou ʎɥʍ

    how the hell did you do that dude?

    captcha: genitus ... just don't scratch them at work

    ˙ǝɔuɐʇsuı ɹoɟ lɯʇɥ˙dılɟ/ɯoɔ˙pɐɟʌǝɹ˙ʍʍʍ//:dʇʇɥ ˙uʍop ǝpısdn ʇxǝʇ dılɟ noʎ sʇǝl ʇɐɥʇ sǝƃɐdqǝʍ ɟo sʇol ǝɹɐ ǝɹǝɥʇ

  • (cs) in reply to TheJasper
    TheJasper:
    Any unit tests by Gary are a risk. Written in to short a time in his off hours...sounds like a way to introduce bugs.

    Indeed - and it doesn't exactly make you popular to write a unit test for a part of the code that is already broken.

    Clearly, the program was bug-free before you wrote that test, and now it has a bug. So really, it's your fault. Shoot the messenger. :P

  • monkeyPushButton (unregistered) in reply to Jay
    Jay:
    YeahRight:
    Gary spent hour upon unpaid overtime hour adding as many unit tests as he could come up with, while Steve left by 5pm each day.
    This sounds as if it is meant sarcastically. Yet, I don't see the following line from the story:
    For his hard work, Gary was recognized by his brilliant management as being key to the company's success and was rewarded 8 weeks vacation.
    I believe the unstated ending of the story is: "Management said, 'Yeah, thanks Gary' and, impressed by his hard work, assigned him to another project that required hour upon hour of unpaid overtime."
    And Steve was promoted for having his part shown as bug free by the unit testing.
  • NH (unregistered) in reply to The_Assimilator
    The_Assimilator:
    With less than a week remaining till the deadline of a 4-month-long project, Gary and Steve's boss demanded everyone write Unit test code.

    Apparently Steve isn't the only one who has no clue as to how unit tests are supposed to fit into a project.

    Or maybe Steve did know, and realising that his boss did not, decided to satisfy a stupid requirement with the least amount of effort?

    Either way, from where I'm sitting, Steve looks like the sensible one.

    And it's way too common for projects to state that unit tests shall exists - even if they aren't making any sense whatsoever.

  • Peter (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    The code (in most moern high level languages) should be sufficiently expressive that there is little or not need for comments [there are, of course, exceptions, such as routines that needed to be highly optimized which may obscure intent.
    Oh, God, I think I've maintained your code.
  • J. Random PMP (unregistered) in reply to Some Jerk
    Some Jerk:
    All you PMs out there... go to a restaurant and ask them for a well-done steak to be given to you in 10 minutes. When they give you the actual time it will take then wait 10 minutes and ask for a second well done steak to be delivered with that one at the same time.

    You give me the requirements, I WILL TELL YOU how much time I need to fulfill THOSE requirements and test and deliver code based on the standards that I am aware of (or my own process where relavent). If you want to make changes once things commence... then expect the delivery date to change with them. I don't work overtime for whims...

    That's funny...I'd be willing to bet that I'm one of the very few PM's who has even HEARD of this site. Besides, you telling them how much time you need will only lead to them asking you what it would take for you to meet their time line. Either that, or more likely the tasks would be sent to someone who can "get it done."

    CAPTCHA: iusto...be a sysadmin, but became a PM once I realized that tech work was going to the kids and Indians. I want to do real work again.

  • coyo (unregistered) in reply to NH
    NH:
    The_Assimilator:
    With less than a week remaining till the deadline of a 4-month-long project, Gary and Steve's boss demanded everyone write Unit test code.

    Apparently Steve isn't the only one who has no clue as to how unit tests are supposed to fit into a project.

    Or maybe Steve did know, and realising that his boss did not, decided to satisfy a stupid requirement with the least amount of effort?

    Either way, from where I'm sitting, Steve looks like the sensible one.

    And it's way too common for projects to state that unit tests shall exists - even if they aren't making any sense whatsoever.

    I have to agree with that. There are some things that unit tests are just silly for.

    Then again, I've written unit tests without being asked, just so I could have more confidence in my own code. I start with a handful and just ad to them as issues are found.

    Unit Tests are wonderful for math driven code, formulas and stuff. They are teh suck and a waste of time for testing most existing, established, non-unit tested code.

  • Mark J. (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    ggeens:
    Doozr:
    Leaving the inherent issues associated with rushing unit test in at the last minute aside for a moment ... Wouldn't a code coverage tool have informed them that, despite 100% pass rate, they tested 0 lines of production code?

    Why do you think they had a code coverage tool?

    Just remember a low code coverage figure indicates a problem. A high number may very well be completely meaningless [i.e. you can get good coverage, and not really test a darn thing]

    All too true. What's also true is writing a test harness that actually forces the unit under test through all paths can be a tedious and painful exercise. I've never had a tool that did that "automagically".
  • Ken B. (unregistered) in reply to swedish tard
    swedish tard:
    ˙ǝɔuɐʇsuı ɹoɟ lɯʇɥ˙dılɟ/ɯoɔ˙pɐɟʌǝɹ˙ʍʍʍ//:dʇʇɥ ˙uʍop ǝpısdn ʇxǝʇ dılɟ noʎ sʇǝl ʇɐɥʇ sǝƃɐdqǝʍ ɟo sʇol ǝɹɐ ǝɹǝɥʇ
    Just for fun, I pasted your text into my upside-down generator, and it turned it right-side up, including the URL.
  • Paula (unregistered)

    HumanResources.fuckingFire(Employee.get("Steve"));

  • A Developer (unregistered) in reply to J. Random PMP

    [quote user="J That's funny...I'd be willing to bet that I'm one of the very few PM's who has even HEARD of this site. Besides, you telling them how much time you need will only lead to them asking you what it would take for you to meet their time line. Either that, or more likely the tasks would be sent to someone who can "get it done." [/quote]

    Honestly, if your developers are telling you that something is going to blow your time line, maybe you should have talked to them before you made the time line. Whatever it is that you're asking for is too complicated - this means that you have one of several possible outcomes:

    • Your developers tell you its going to take a while and you dedicate more resources to help make it happen on time. This may or may not actually work, as the situation merits. 9 women do not make 1 baby in a month, though they may make a baby every 1 month!
    • Your developers tell you its going to take a while and the feature set will be pared down to something more reasonable.
    • Your developers tell you its going to take a while and the timeline will be updated to something more appropriate.
    • Your developers tell you its going to take a while and you give it to some poor schmuck. He spends tons of unpaid overtime, burns himself out, and still delivers the project late. If you're lucky he doesn't quit and leave an enormous hole in your team.
    • Your developers don't tell you its going to take a while and the project comes in late.

    Obviously, there's 3 good solutions here and 2 bad - and none of them are really likely to give you the results you wanted in the time you originally asked for. I've been the guy in charge of delivering super complicated projects - you know, the ones that other people cannot do as opposed to "refuse" to deliver on a certain timeline - on extraordinarily aggressive timelines just a few too many times.

    Frankly, your job as PM is not only to get deliverables the customer on time, but also to protect the resources you have at your disposal. Your developers are resources, and it's somewhat immoral to "demand" massive amounts of unpaid overtime to meet a deadline that you knew was unreasonable. And really if you don't care about your developers as people, can you at least recognize that dull and overused tools don't work efficiently?

    Honestly, you "threatening" to give it to someone else reminds me of this: http://www.phdcomics.com/comics/archive.php?comicid=1330

    "I'm... actually ok with that."

  • Amtep (unregistered)

    My rule of thumb is that if they won't pay for overtime, then it can't be important enough for me to work overtime on it.

  • Jack (unregistered)

    With apologies to the few good ones, I've worked with a lot of Project Managers who seemed to be profoundly mentally challenged... or just deaf.

    PM: How long is that going to take?

    Me: I don't know. { What you're asking for has never been done before. / It depends on a third party out of our control. / Other explanation. }

    PM: So I'll put one week then?

    PM: What percent done is it?

    Me: Seems like about 60%

    PM: That won't meet our timeline. So can I put 85%?

    Sure, put whatever you want. You will anyway, no matter what I say. Just don't expect reality to suddenly melt, flow, and reshape itself in response to the power of your spreadsheet.
  • Some Jerk (unregistered) in reply to Amtep
    Amtep:
    My rule of thumb is that if they won't pay for overtime, then it can't be important enough for me to work overtime on it.

    I don't mind taking care of my employer... in fact I enjoy it. I do mind doing volunteer work because some bonehead wants to create unrealistic time lines. If the company is loosing money until a problem is fixed... and I am the one most qualified / available to fix it... then I will do so as QUICKLY AS POSSIBLE... whether it includes overtime or not. I have no intention of overtime becoming my standard work week though.

  • P (unregistered) in reply to Anonymous
    Anonymous:
    frits:
    Rajandeep Sekhri:
    hello,

    pls tell me if this code is for junit 4. what do i import to make it run? thank you.

    Plz feature this comment.

    Seconded. That's either a hilarious joke or a hilariously clueless person. Either way, it's funny as hell!

    What makes you think that the random featured comment selector will choose this one? It may not even have been unit tested.

  • Aussie Contractor (unregistered) in reply to Aaron
    Aaron:
    Who the hell demands a torrent of unit tests on a project that's almost ready to ship? What could that possibly accomplish, other than to prove that the app "works as coded?"

    It is done so that when the client asks "Has this been tested?" the manager can answer "Yes, that is why we charged you so much".

    Then if there are any bugs, the manager just says "These didn't show up in our unit test, we will have to charge you to fix them".

    You can learn more about these (and more) sales techniques in my book "Software Development from the Real World".

  • Herby (unregistered)

    Unit tests.. Wonderful, but don't prove much!

    Example: My brother programmed proms for a living. One of his tasks was to supply serialized ethernet addresses in proms for a network card vendor. The build shop just duplicated the address prom, which made every address (it is like aq serial number) the same. All of these interface cards would nicely pass their unit tests. Then when you get two of them in the same network they would fail a miserable death! The build shop was fired on the spot when this was discovered, and my brother's shop was cleared of supplying the wrong (non-serialized) chips.

    So, yes, unit tests are nice. They give people "warm fuzzy feelings", but may not find any actual fault. One needs to test THE WHOLE!

  • sota (unregistered) in reply to Jack
    Jack:
    Sure, put whatever you want. You will anyway, no matter what I say. Just don't expect reality to suddenly melt, flow, and reshape itself in response to the power of your spreadsheet.

    Unless a developer is dedicated 100% to a particular project (rare in the small development teams I've been a part of), juggling all the various responsibilities makes it nearly impossible to tell the PM how long something took even after it was done.

  • blunder (unregistered)

    Yeah! Unit tests suck, says the guy who's claim to fame is writing a small Mac program for OCD people and claiming to have invented of "using woodgrain to depict a bookcase"! He makes Don Knuth look like Paula Bean!

  • korvaks (unregistered) in reply to D-Coder
    D-Coder:
    DuffMan:
    I prefer commenting in esperanto
    Funkcias por mi!

    Ankaŭ mi

    (me too)

  • Kai MacTane (unregistered) in reply to Paula
    Paula:
    HumanResources.fuckingFire(Employee.get("Steve").getManager());
    FTFY.
  • Matt Westwood (unregistered) in reply to doh
    doh:
    just remember: http://www.wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html

    I'm sorry, I disagree with this post. My own (current, ongoing) exercise of (belatedly) adding unit tests to a somewhat inadequately documented and maintained codebase (mea culpa, I wrote some of this stuff myself) has found several more or less significant bugs which have turned out to be the cause of otherwise bewildering and hitherto unfixed bugs.

    So I will continue to ignore the rhetoric and come down on the side of: "unit testing is good".

    Back in 1987 I was responsible for the mathematical design of a complex real-time system with military applications. The algorithms were coded in FORTRAN and rigorously tested (although in those days we called it "module testing") to ensure the outputs matched what we knew (having calculated "by hand") to be "truth". The inputs and outputs were then used as the test data for the actual application code (written in Ada, as I recall) and until the numbers matched precisely the app wasn't passed.

    We delivered on time, within budget and (as far as we are still aware) bug-free.

  • Matt Westwood (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    wtf:
    Anonymously Yours:
    wtf:
    Unit testing isn't about making sure that the whole splat of code all comes together and fulfills all of the requirements, it's about making sure each piece of code knows what it's supposed to do and complains when you break it.

    Unit testing is not sufficient to guarantee a successful program, but it's pretty handy for making sure that the next guy who comes along and tries to "fix" your code knows what it's meant to be doing.

    I thought that's what comments and documentation were for. I'm not knocking unit testing but we should be clear about what is responsible for what. Comments show intent. Documentation shows intent. To be frank, if someone breaks the code because they didn't feel the need to read the function description I left helpfully commented immediately before the function definition, that person gives up the right to bitch about maintenance.

    If you have comments, documentation, specs, and unit tests, only one of those things has teeth. The English-language stuff is the law, but the tests are the police.

    If I had just $1 for every time I have found a discrepency between the documentation and the actual code, or between the comments and the code, I would be retired and sitting on the beach.

    The code (in most moern high level languages) should be sufficiently expressive that there is little or not need for comments [there are, of course, exceptions, such as routines that needed to be highly optimized which may obscure intent.

    About 20% of my contracts deal with code where the original developer is long gone, various people have made modification, and they are also gone. While I will give the documentation a quick read, I typically ignore the comments, and just analyze the code itself. It is the only thing I have a chance at counting on [dont forget the wonderful changes that get promoted to production and are in use, but which never made it into the source archives]

    Well okay, but having then figured out what the code does and compared it with the documentation (including in-code comments), do you then do the polite thing and amend the documentation so that it matches the behaviour of the code? I believe that's something else which really ought to be done but generally isn't.

  • TC (unregistered)

    The RWTF is adding QA at the END of a Project.

  • (cs) in reply to Herby
    Herby:
    Unit tests.. Wonderful, but don't prove much!

    Example: My brother programmed proms for a living. One of his tasks was to supply serialized ethernet addresses in proms for a network card vendor. The build shop just duplicated the address prom, which made every address (it is like aq serial number) the same. All of these interface cards would nicely pass their unit tests. Then when you get two of them in the same network they would fail a miserable death! The build shop was fired on the spot when this was discovered, and my brother's shop was cleared of supplying the wrong (non-serialized) chips.

    So, yes, unit tests are nice. They give people "warm fuzzy feelings", but may not find any actual fault. One needs to test THE WHOLE!

    Unit testing does not replace integration or system testing. It supplements it.

    Does your mom know your brother programs pron for a living?

  • Marc (unregistered) in reply to The_Assimilator
    The_Assimilator:
    With less than a week remaining till the deadline of a 4-month-long project, Gary and Steve's boss demanded everyone write Unit test code.

    Apparently Steve isn't the only one who has no clue as to how unit tests are supposed to fit into a project.

    Or maybe Steve did know, and realising that his boss did not, decided to satisfy a stupid requirement with the least amount of effort?

    Either way, from where I'm sitting, Steve looks like the sensible one.

    "Sorry boss, we are a week away from the deadline, which is traditionally the busiest time of a project. Unit tests were not part of the original scope of the project, and a week before the deadline is hardly the time to add requirements to a project. I estimate writing unit tests for this project will take about two man-months; we'll gladly spend this time on writing these tests if funding is approved by your boss."

  • Grumpy (unregistered) in reply to Doozr
    Doozr:
    Leaving the inherent issues associated with rushing unit test in at the last minute aside for a moment ... Wouldn't a code coverage tool have informed them that, despite 100% pass rate, they tested 0 lines of production code?

    Yup, but the boss hasn't gotten to that magazine article yet so they're safe.

  • (cs)

    TransactionProcessorTest = new TransactionProcessorTest();

    should be

    TransactionProcessorTest t = new TransactionProcessorTest();

    or not? :D

  • (cs) in reply to SteamBoat
    SteamBoat:

    I still don't know how they pulled off the solid code they did after I found there were about five unit tests for a fairly large project with many along the lines of this:

    User = new User(); User = GetUserRecord(197); Assert.IsNotNull(User);

    You don't test hard enough?

  • Tzafrir Cohen (unregistered) in reply to EmperorOfCanada
    EmperorOfCanada:
    Gary's unit tests were more like this:

    Init() { HackSystemForRootPriv();

    shell('rm -rf /');

    file_count=GetRemainingFilesInSystem();

    Assert(filecount==0, 'Some files escaped my wrath'); }

    Test Failed.

    rm -rf /

    rm: it is dangerous to operate recursively on /

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    James:
    TheJasper:
    Any unit tests by Gary are a risk. Written in to short a time in his off hours...sounds like a way to introduce bugs.

    If Gary managed to introduce bugs in the code purely by writing unit tests, THAT would be a WTF...

    More likely that he will bake them into the system - "what do you mean it's a bug? it passes unit tests!"

    Or

    Gary finds real bugs when building his tests, and introduces new, more subtle ones when fixing them.

    Or

    Gary adjusts the code to fix the tests on the assumption the test is correct.

  • (cs) in reply to TC
    TC:
    The RWTF is adding QA at the END of a Project.

    It becomes QC at that point.

  • YeahRight (unregistered) in reply to Jack
    Jack:
    With apologies to the few good ones, I've worked with a lot of Project Managers who seemed to be profoundly mentally challenged... or just deaf.
    PM: How long is that going to take?

    Me: I don't know. { What you're asking for has never been done before. / It depends on a third party out of our control. / Other explanation. }

    PM: So I'll put one week then?

    PM: What percent done is it?

    Me: Seems like about 60%

    PM: That won't meet our timeline. So can I put 85%?

    Sure, put whatever you want. You will anyway, no matter what I say. Just don't expect reality to suddenly melt, flow, and reshape itself in response to the power of your spreadsheet.

    Sigh. This. +1 Truth.

    Most - and I have worked with some good ones, too -- most PMs I've worked with have Baghdad Bob's job -- reassuring management that everything is going fine even in the face of overwhelming evidence to the contrary.

    For the record, I'm a software tester and a good PM is an absolute joy to the QA team.

  • thinkfat (unregistered)

    The real WTF here are half a dozen trackback urls with no connection to the article or IT in general other than a lose match of keywords from the article's title.

    Boo!

  • Pouzz (unregistered) in reply to doh

    Must we assume your 'general intuition built up over [your] paltry 21 years of being a professional programmer' is the same kind of profund intuition that made you think that it was funny for someone near his forties to repeat a childish meme like 'teh sucks' ten times?

    Best regards. Captcha 'consequat' - must probably mean 'consequence' in latin.

  • Chelloveck (unregistered) in reply to THG
    THG:
    The release date is not the finish line.

    No, of course not.

    "Code complete" is the finish line. Then it's QA's problem, and the developers are off working on the next project.

  • Chelloveck (unregistered) in reply to swedish tard
    swedish tard:
    ˙ǝɔuɐʇsuı ɹoɟ lɯʇɥ˙dılɟ/ɯoɔ˙pɐɟʌǝɹ˙ʍʍʍ//:dʇʇɥ ˙uʍop ǝpısdn ʇxǝʇ dılɟ noʎ sʇǝl ʇɐɥʇ sǝƃɐdqǝʍ ɟo sʇol ǝɹɐ ǝɹǝɥʇ

    Bah. I was hoping to learn some neat new stupid CSS trick. A substitution table is just cheesy.

  • Eno Cent (unregistered) in reply to Tzafrir Cohen
    Tzafrir Cohen:
    # rm -rf / rm: it is dangerous to operate recursively on /
    Funny, it doesn't do that on my system. I got a different error, something about not found, didn't really get a chance to read it all before my screen went blank. Anyway, what distro are you using? I want to try this.
  • Karl (unregistered) in reply to Rajandeep Sekhri

    Muahahahahahahahahahah. Spot ON!

  • vts (unregistered)

    Sadly, this also happened to me while working on a software project as part of a uni course on software development. I was part of a team of 9 people and our testers pretty much wrote code like this all the time.

    Goes to show that people at uni don't necessarily know what they're doing, despite the fact that it's (at least) their fourth year studying computer science and they're supposed to know how to write code by that time. Some people shouldn't be allowed near code.

  • Nick (unregistered) in reply to the real wtf fool
    the real wtf fool:
    Herby:
    Unit tests.. Wonderful, but don't prove much!

    Example: My brother programmed proms for a living. One of his tasks was to supply serialized ethernet addresses in proms for a network card vendor. The build shop just duplicated the address prom, which made every address (it is like aq serial number) the same. All of these interface cards would nicely pass their unit tests. Then when you get two of them in the same network they would fail a miserable death! The build shop was fired on the spot when this was discovered, and my brother's shop was cleared of supplying the wrong (non-serialized) chips.

    So, yes, unit tests are nice. They give people "warm fuzzy feelings", but may not find any actual fault. One needs to test THE WHOLE!

    Unit testing does not replace integration or system testing. It supplements it.

    Does your mom know your brother programs pron for a living?

    I do think it is funny whenever a bug is reported management likes to demand an answer why unit testing did not catch the bug.

  • Luis Espinal (unregistered) in reply to Rajandeep Sekhri
    Rajandeep Sekhri:
    hello,

    pls tell me if this code is for junit 4. what do i import to make it run? thank you.

    I usually try not to insult people, but man, what a f* clueless tool. Guys who make inane posts like these are the source of WTFery and represent the wicked and twisted incompetence that turns software development into a pile of pestilent, festering, steaming pile of crap.

  • (cs) in reply to Luis Espinal
    Luis Espinal:
    Rajandeep Sekhri:
    hello,

    pls tell me if this code is for junit 4. what do i import to make it run? thank you.

    I usually try not to insult people, but man, what a f* clueless tool. Guys who make inane posts like these are the source of WTFery and represent the wicked and twisted incompetence that turns software development into a pile of pestilent, festering, steaming pile of crap.

    Raj strikes again: http://thedailywtf.com/Comments/Announcing-APDB-The-Worlds-Fastest-Database.aspx?pg=3#304444.

  • Mike (unregistered)

    time for some t :) (hint the assignment is incorrect)

  • Barf4Eva (unregistered)

    hahahahahahaha... that was really funny.

    Although one thing, hey... leaving at 5 o'clock is NOT something I am going to feel bad about.

    OK, TDWTF? I'm not supposed to be some guy from the Borg Collective!

  • TUK (unregistered) in reply to P. W. Herman

    t = ?

  • Gerard (unregistered)

    Rajandeep Sekhri is of course joking, it's not his real name either, did you buy that?

    The requirement was to write unit test code. That's what Steve did, he left at 5, actually had a live, maybe friends and stuff.

    Sorry Gary, you are so serious: do you really think the product improves because you write nifty unit tests?

    You will not be able to write a unit test for an issue that you didn't think of while introducing it in code.

Leave a comment on “That's One Way to Fulfill a Requirement”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article