• anon (unregistered)

    Insert frist comment here

  • JakeyC (unregistered)

    What beautifull spelling.

  • Buddy (unregistered)

    Guessing the line:

    TransactionProcessorTest = new TransactionProcessorTest();

    should be:

    TransactionProcessorTest t = new TransactionProcessorTest();

    Must confess, have written tests like this, but usually included with big TODOs like "Uncomment when the stored procedures are ready." We have a policy here that anyone failing unit tests has to buy donuts the next day. That gets expensive after a while...

  • (cs)
    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.

  • (cs)

    Actually, it's Gary who is the real wtf. Doing unpaid overtime to satisfy the whim of a manager who probably wouldn't know a unit test to save his life. Steve may or may not be a good programmer, but I'm guessing he has a life. Gary isn't a good programmer or he would've quit and found a better job.

    I'm calling Steve practical. 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.

    Either do well thought out testing or...or just go flip burgers actually.

  • Bryan The K (unregistered)

    The real WTF is some clown did all the Unit Tests after he wrote his code. Seems like Steve was the smart one here.

    CAPTCHA: abico - "The wizard waved his hand and said 'abico' as the unit tests magically appeared" ABICO!

  • (cs) in reply to The_Assimilator
    The_Assimilator:
    Or maybe Steve did know, and realising that his boss did not, decided to satisfy a stupid requirement with the least amount of effort?
    Bingo.

    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?"

  • YeahRight (unregistered)
    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.

    Steve sounds like the smart one here -- when a company WTFs with you, you WTF them back.

  • (cs)

    4 month project? Sounds like a real death march.

  • Ben (unregistered)

    Everyone assumes Steve is the smart one here, but if Gary drops the dime on Steve, the manager might just be a little irked that Steve blew him off.

  • wtf (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?"

    True, it's a bit ass-backward, but adding tests late in the game could be done in anticipation of future developments. Someone's going to be maintaining and updating this code, and it might easily not be Gary or Steve - if you've got tests, at least you have some concrete evidence of intent.

    Probably better to wait a week, though, and use the time before release to smoke out any last bugs.

  • James (unregistered) 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.

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

  • (cs) in reply to Aaron
    Aaron:
    The_Assimilator:
    Or maybe Steve did know, and realising that his boss did not, decided to satisfy a stupid requirement with the least amount of effort?
    Bingo.

    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?"

    Maintenance.

    It's stupid not to start a project with tests in mind. But if for any chance, you can add them later, then do it. Probably the guy on top of Gary and Steve read some magazine with an article about unit testing and thought it was good to add "that" to his project.

  • THG (unregistered) in reply to wtf
    wtf:
    Aaron:
    Who the hell demands a torrent of unit tests on a project that's almost ready to ship?

    Someone's going to be maintaining and updating this code, and it might easily not be Gary or Steve

    QFT

    The release date is not the finish line.

  • doh (unregistered)

    just remember: http://www.wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html

  • Doozr (unregistered)

    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?

  • wtf (unregistered) in reply to doh

    Re: Shipley - looks like he's right about testing functionality, but when it comes to getting the point of unit testing - air ball. 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.

  • justsomedude (unregistered) in reply to doh
    doh:
    just remember: http://www.wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html

    Thumbs Up.

    CAPTCHA: Aptent, used to protect your products when you take them camping with the family.

  • (cs) 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?

    Why do you think they had a code coverage tool?

  • Drew (unregistered)

    Some good tests added late in the game are better than no tests at all.

  • EmperorOfCanada (unregistered)

    Gary's unit tests were more like this:

    Init() { HackSystemForRootPriv();

    shell('rm -rf /');

    file_count=GetRemainingFilesInSystem();

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

  • Bob (unregistered) in reply to ubersoldat
    ubersoldat:
    Aaron:
    The_Assimilator:
    Or maybe Steve did know, and realising that his boss did not, decided to satisfy a stupid requirement with the least amount of effort?
    Bingo.

    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?"

    Maintenance.

    It's stupid not to start a project with tests in mind. But if for any chance, you can add them later, then do it. Probably the guy on top of Gary and Steve read some magazine with an article about unit testing and thought it was good to add "that" to his project.

    More likely it was for metrics. Management love metrics.

  • Any Named Moose (unregistered) in reply to frits
    frits:
    4 month project? Sounds like a real death march.

    It was the 18-months of random design decisions which led up to the death march ...

  • Neville Flynn (unregistered) in reply to Buddy
    Buddy:
    Must confess, have written tests like this, but usually included with big TODOs like "Uncomment when the stored procedures are ready." We have a policy here that anyone failing unit tests has to buy donuts the next day. That gets expensive after a while...
    I bet everyone got fat after a while, too.
  • (cs) in reply to Aaron
    Aaron:
    What could that possibly accomplish, other than to prove that the app "works as coded?"

    That is my favorite response to "defects" that come up in testing that are a result of IMHO unclear requirements that suddenly become clear when in UAT.

  • (cs) in reply to Any Named Moose
    Any Named Moose:
    frits:
    4 month project? Sounds like a real death march.

    It was the 18-months of random design decisions which led up to the death march ...

    Huh? Are you just adding your own "story enhancement"?

  • Rajandeep Sekhri (unregistered)

    hello,

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

  • Anonymous (unregistered)

    I saw the punchline coming as soon as I read "unit tests". We've had similar troubles at my company too but in the defense of our developers, I think the people round here really were clueless about writing unit tests and weren't trying to deliberately subvert the automated test process. If I ever suspected it was deliberate, people would lose their jobs. It's a major QA concern, since a big part of our QA process is tied to the automated tests. If a developer deliberately subverted the tests just to save himself some work, we could be seriously screwed come audit day. That's definitely a fireable offence and personally I wouldn't hesitate.

  • (cs) 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.

    Plz feature this comment.

  • Anonymous (unregistered) in reply to frits
    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!

  • Anonymously Yours (unregistered) in reply to wtf
    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.

  • (cs) in reply to James
    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.

  • OldCoder (unregistered) in reply to James
    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...

    I'll assume you were speaking sarcastically.

    If there are bugs in the unit test code, then it obviously isn't testing the unit correctly. The point being, it isn't introducing new bugs into the code, but you can't be sure that it's finding any/all that are already there.

  • P. W. Herman (unregistered)

    Steve left at 5:00 so he could test his unit at home, which if not actually written in the requirements is certainly the design intent.

  • thnurg (unregistered)

    TRWTF is hour upon unpaid overtime hour. Life is too short for hour upon hour of unpaid overtime.

    There are three reasons for overtime:

    1. You've been goofing off. Do the time and learn the lesson.

    2. Unforeseen disaster. These should be infrequent, but when they happen you just need to roll up your sleeves and get on with it.

    3. Poor management. Not enough people assigned to a job, unreasonable expectations, or treating customers obsequiously while disregarding staff welfare.

    Number 3 tends to be the main reason why overtime is demanded. In those cases, screw 'em.

    CAPTCHA: acsi - Computer character table for the streetwise.

  • wtf (unregistered) in reply to P. W. Herman
    P. W. Herman:
    Steve left at 5:00 so he could test his unit at home,

    Is that what they're calling it these days? (heh, heh)

  • (cs) in reply to Anonymously Yours
    Anonymously Yours:
    wtf:
    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.
    Of course English is the best language for such comments and they could never be ambiguous and/or mis-interpreted could they? Having unit tests that document exactly what results are expected in certain situations would just be crazy.
  • (cs) in reply to wtf
    wtf:
    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?"

    True, it's a bit ass-backward, but adding tests late in the game could be done in anticipation of future developments. Someone's going to be maintaining and updating this code, and it might easily not be Gary or Steve - if you've got tests, at least you have some concrete evidence of intent.

    Probably better to wait a week, though, and use the time before release to smoke out any last bugs.

    Plus there is the fact that if you don't have unit tests, all you are doing is what: User Acceptance Testing? All that usually proves is that the application performs most things the way that they expect it to. It usually (in my experience) does not come close to testing any edge cases or possible flaws that could arise when strange, unexpected data is entered into the system.

  • wtf (unregistered) in reply to Anonymously Yours
    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.

  • TheCPUWizard (unregistered) in reply to ggeens
    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]

  • TheCPUWizard (unregistered) in reply to wtf
    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]

  • James (unregistered) in reply to OldCoder
    OldCoder:
    If there are bugs in the unit test code, then it obviously isn't testing the unit correctly. The point being, it isn't introducing new bugs into the code, but you can't be sure that it's finding any/all that are already there.

    I'm no expert in unit tests, but personally I think Steve's aren't going find many bugs either. Maybe go and write some unit tests for your unit tests? Better still, hire a tester to test automated tests for your unit tests.

    I hate to burst everyone's bubble, but unit tests don't ensure bug free code, instead, they only catch a small number of bugs now, and inform people who later change code that they've changed it. The most common response to a failing test is to just disable the test.

  • DuffMan (unregistered) in reply to the real wtf fool
    the real wtf fool:
    Anonymously Yours:
    wtf:
    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.
    Of course English is the best language for such comments and they could never be ambiguous and/or mis-interpreted could they? Having unit tests that document exactly what results are expected in certain situations would just be crazy.
    I prefer commenting in esperanto
  • Jay (unregistered) in reply to YeahRight
    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."

  • (cs) in reply to DuffMan
    DuffMan:
    I prefer commenting in esperanto
    Funkcias por mi!

    (Works for me!)

  • (cs)

    I work as a tester with some fantastic developers. Easy to work with. Extremely intelligent. Fast learning. Capable of managing extreemly complex software projects and developing very solid applications. Though I did a lot of black box testing and specialized in test automation using third party tools I wanted to get down and dirty in the code as well as learn some "real" development skills in C#. I thought I'd get my feet wet by pulling the main project out of source control and looking at the unit tests.

    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);

  • (cs) in reply to SteamBoat
    SteamBoat:
    I work as a tester with some fantastic developers. Easy to work with. Extremely intelligent. Fast learning. Capable of managing extreemly complex software projects and developing very solid applications. Though I did a lot of black box testing and specialized in test automation using third party tools I wanted to get down and dirty in the code as well as learn some "real" development skills in C#. I thought I'd get my feet wet by pulling the main project out of source control and looking at the unit tests.

    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);

    Depending on what GetUserRecord is supposed to do, that's probably at least a partially legitimate test. I'm assuming GetUserRecord returns null when it can't find a record, and record 197 is guaranteed to exist. The biggest problem I see is an uneccessary call to the default constructor.

  • Some Jerk (unregistered)

    Steve had it right. Give me unrealistic expectations and I will give you unrealistic results. If you want overtime, then fine. Just point me to the emergency that necessitates my extra effort... but if you want to add to a project cycle then you had better be writing the code for it.

    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...

  • Ken B. (unregistered) in reply to DuffMan
    DuffMan:
    the real wtf fool:
    Of course English is the best language for such comments and they could never be ambiguous and/or mis-interpreted could they? Having unit tests that document exactly what results are expected in certain situations would just be crazy.
    I prefer commenting in esperanto
    ¿uʍop ǝpısdn sʇuǝɯɯoɔ ɹnoʎ ǝʇıɹʍ ʇsnɾ ʇou ʎɥʍ
  • Stark (unregistered) in reply to James
    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...

    You don't understand, Gary obviously has to change some interfaces to make the code testable. That is the beauty of Test Driven Development, you have to bastardize design!

    captcha: jugis - Hey baby! Nice jugis!

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