• Rev. Jimmy Jones (unregistered) in reply to Anon.
    Anon.:
    Rev. Jimmy Jones:
    Bah, bunch of Kool-Aid drinkers. TDD is inconclusive at best at improving code quality. TDD does add additional code to a project. Since bug frequency is fairly constant per SLC, you may actually be inducing extra defects in your codebase. Not to mention that designing software to conform to unit tests is much like putting the horse before the cart. One proven benefit of TDD is increased productivity, so developers do output more crappy code per time unit. That should make managers happy.

    At this point it's impossible to differentiate between trolling and stupidity. So I won't.

    If TDD doesn't improve the quality of your code, you're doing TFD, or you're just a crap code-smith. It doesn't do the designing of the code FOR you, it just makes it easier for the developer to refactor it (the final R or RGR). It's not MEANT to be a silver bullet that turns incompetent developers into overnight geniuses. And TDD doesn't add additional code to a project, unless you count unit test code as "additional code".

    Designing software to conform to its SPECIFICATION is what TDD is about, and as such writing the unit tests becomes the key skill here.

    Sounds like someone read all about TDD and just "didn't get it".

    Agreed. Dont you know what the first "D" stands for?

    You didn't actually provide any counter argument other than "your not doing it right". There are actual studies that show no correlation between using TDD and improving quality. There is at least one flawed study that attempts to prove (and fails) that is does improve quality. I won't post the links here but you can do the research yourself if you care.

  • consequat (unregistered)

    Didn't Joel Spolsky write an article about this concept? i.e. the instant you establish a performance metric, people will find a way to game the system.

  • (cs) in reply to RayMarron
    RayMarron:
    I don't think I could ever work somewhere that had three HUNDRED developers. How does anything ever get finished with so many hands in the pot? I can just imagine the multi-layer management WTFery.
    Google seems to do ok.
  • Anonymous (unregistered) in reply to consequat
    consequat:
    Didn't Joel Spolsky write an article about this concept? i.e. the instant you establish a performance metric, people will find a way to game the system.
    Only the most idiotic of managers would actually tell their staff it's a measured metric. You never tell your staff how you appraise them, the little shits will just try to work the system.
  • (cs) in reply to Rev. Jimmy Jones
    Rev. Jimmy Jones:
    Not to mention that designing software to conform to unit tests is much like putting the horse before the cart.

    Isn't that where the horse is supposed to go?

  • Juro (unregistered)

    I have similar experience from my previous company. Every test method was in try-catch block. Just to be sure that it works.

    assertEqual in your example is very interesting for me, because our tests did not have any assertions.

  • Anonymous (unregistered) in reply to dgvid
    dgvid:
    Maybe all that management gibberish about "buy-in" actually means something after all.
    No, we don't need no bloody "buy-ins" from developers, these monkeys are paid to do what they're said to. If they aren't doing it - fire them!!!
  • Bim Job (unregistered)

    Mr. Wint: If at first you don't succeed Mr. Kidd...? Mr. Kidd: Try, try again, Mr. Wint.

    Courtesy of Diamonds are forever, here.

  • Bim Job (unregistered) in reply to Bim Job

    Or, and quite appropriately (I apologise for the top-quoting, although I have no earthly idea why I should do so):

    Bim Job:
    Mr. Wint: If at first you don't succeed Mr. Kidd...? Mr. Kidd: Try, try again, Mr. Wint.

    Courtesy of Diamonds are forever, here.

  • Anon (unregistered) in reply to Cliff notes anyone
    Cliff notes anyone:
    Not to shcioking. Bad tests (or poorly writetn tests) are as good as no tests at all.

    The developers need to be on board and want ot do a good job.

    The fix is i nthe reward/punishment system. Figure out how to reward good unit tests and peopel will do them. Publicly blast people for pulling crap like in this example and they will quit (good ridance) or they will start doing their jobs.

    For humor, I had a software lead tell us that unit testing will be done after coding is done. I left the department in part due to this. Software leads and management that don't know how to properly develop software are a formula for hell. Especially if it is like talking to a wall. The good people leave the company and the peopel that don't care about code quality either way stay.

    Clearly this post wasn't unit tested.

  • Beta (unregistered) in reply to computerfreaker
    computerfreaker:
    Beta:
    ...start evaluating and rewarding developers by how many unit-level bugs they create/tolerate/fix.
    http://thedailywtf.com/Articles/The-Defect-Black-Market.aspx Need I say more?
    The spam filter is blocking my reply, but this effect was known earlier (see http://www.dilbert.com/1995-11-13), and I chose my words carefully.
  • Jeff K. (unregistered)

    So my question is, whey didn't write something to reflect on all the classes and methods to call them all? If they really wanted to avoid the tedium of writing all those pesky tests, they could have had 100% code coverage in just one method!

    I personally don't blame Ian for this mess. It takes a lot of effort to change the culture of a development shop that only knows one way of doing things. In my experience, this is especially true if that way is wrong, because they've probably already been told numerous times that it's wrong, and they've been too stubborn or had too much pride to change their ways up until now. As the saying goes, "you can lead a horse to water, but you can't make him code tests," or something like that.

  • EngleBart (unregistered) in reply to Beta
    Beta:
    ...

    If the sweet approach doesn't work, and the developers are just mule-headed, try some Machiavelli: start evaluating and rewarding developers by how many unit-level bugs they create/tolerate/fix. Make it fast (scoreboard on the wall) and slow (bonuses, raises, promotions). They don't have to write good unit tests, but those who do will pull ahead fast. And if that doesn't work, try Darwin: hire and fire.

    Following this trend, hire a likable, temp worker as a mole. Give them some budget to take other developers out to lunch and drinks on the temp. The mole can talk B.S. to the other devs about how they are not unit testing. Mole checks in some poor code like the sample.

    Fire the mole for checking in the poor code! Make sure all of the other devs know why the temp/mole was fired.

    See how fast the sloppy unit tests are upated.

  • David (unregistered)

    I really don't see how you failed. If you're truly a consultant, then your sphere of authority is limited: all you can do is provide consultation and recommendations. A Manager or Team Lead who lets this type of unit test pass without comment has failed.

  • Buffled (unregistered) in reply to Anon.
    Anon.:
    And TDD doesn't add additional code to a project, unless you count unit test code as "additional code".
    Erm, and what do you call it? Developer hours are spent writing it, testing the test code, and tweaking the test code to be more effective. That code does not write itself. By any logical measure, you *must* count that as "additional code".
  • sino (unregistered) in reply to Aaron
    Aaron:
    Anonymous:
    I'm perfectly happy writing unit tests, it's just that I don't want to put the testers out of work. If you've got 100% test coverage and your tests are run as part of a continuous integration then you've effectively put those poor girls on the test-desk out of work. They're the only female staff members we've got so I'm certainly not going to be the one to make them redundant. I'm a people person, you see.
    Obvious troll is obvious.
    Sexy troll has grrrrls on the internets.
  • gizmore (unregistered)

    Looks like good code to me.

    try { do_the_dishes(); } catch(Exception e) { do_the_dishes(); // second call might be success; }

    // Do not try further

  • Befuddled (unregistered) in reply to Anonymous
    Anonymous:
    Befuddled:
    300 developers == fail. Simple as that.
    Are you serious? A major international company, over 70 sites worldwide. 300 devs, that's about 4 devs per site - and you think this is too much, "simple as that"? Your comment is quite ridiculous given that you know nothing of the company in question. Your screen name is painfully appropriate.
    I've worked for enough large multinationals to know that when someone refers to one as a 300-developer company it really is as simple as that.

    Human behaviour in groups that large is sadly predictable. People start to value consistency for it's own sake and things go downhill fast from there ending in rampant presenteeism and job losses.

    CATS:
    Befuddled:
    If profit increased despite expenditure doubling income must have more than doubled...
    I may have confused the definitions of Profit and Income, but Wikipedia apparently agrees with me: http://en.wikipedia.org/wiki/Income_statement

    I specially quote: "income statement (as the name implies) takes several steps to find the bottom line, starting with the gross profit. It then calculates operating expenses and, when deducted from the gross profit, yields income from operations. "

    Yanks abusing English and wiki being wrong - shocker /shrug.

    Profit is income - expenditure.

  • quisling (unregistered) in reply to Buffled
    Buffled:
    Anon.:
    And TDD doesn't add additional code to a project, unless you count unit test code as "additional code".
    Erm, and what do you call it? Developer hours are spent writing it, testing the test code, and tweaking the test code to be more effective. That code does not write itself. By any logical measure, you *must* count that as "additional code".
    You might be focusing on a fairly trivial nit, here, but, hey, whatever. Anon. was silly enough to state it in an ambiguous manner.

    It's "additional code" to a team that has no unit tests. It's not to a team that does.

    Additionally, it's arguable that having the usage nailed down ahead of time prevents a slew of errors that require rewriting the codebase (each change is "additional code") once you actually get around to consuming it (I've personally fought this one on many, many, many projects - Over-frameworking is a classic blunder of "senior" developers and architects, which eventually leads down the path to the Inner Platform Effect).

    But none of this is the point. These are beneficial side effects of the pattern. The pattern is about STATING YOUR BUSINESS FACTS AND REQUIREMENTS IN AN AUTOMATABLE FASHION.

    Doing this before writing the implementation (there's that first 'D', Rev. Jimmy Jones!) prevents you from writing gobs and gobs of "this should be useful" "additional code" that you quite simply don't need, or from having to go back in and fix with "additional code" your initial and poorly thought out usage.

    And this, i can only fucking hope, was Anon.'s (not really that) veiled point.

  • sino (unregistered) in reply to Rev. Jimmy Jones
    Rev. Jimmy Jones:
    Bah, bunch of Kool-Aid drinkers. TDD is inconclusive at best at improving code quality. TDD does add additional code to a project. Since bug frequency is fairly constant per SLC, you may actually be inducing extra defects in your codebase. Not to mention that designing software to conform to unit tests is much like putting the horse before the cart. One proven benefit of TDD is increased productivity, so developers do output more crappy code per time unit. That should make managers happy.
    WHOOOOOOOOSSSSHHH!!!
  • Zed (unregistered) in reply to CoderHero
    CoderHero:
    Developers should not be tied to bonuses. Developers have a job to do, and that's it. If they don't like doing what they're supposed to, fire them!
    Writing unit tests takes time. A lot of time. A developers first responsibility is to make the client happy...to keep the money flowing. The client doesn't give a shit about unit tests. They want code quickly...bugs and all.
  • (cs) in reply to Cliff notes anyone
    Cliff notes anyone:
    Not to shcioking. Bad tests (or poorly writetn tests) are worse than no tests at all.
    There, FTFY...
  • KP (unregistered)

    The best way to get developers to test the code, either through automated tests, or whitebox/blackbox testing is to have them carry a support/on-call rotation.

    As soon as developers know that they are going to get a phone call at 2:30 AM (a time that would usually interrupt their WoW session;-), they will test the code.

    I personally don't find unit tests to be very useful or productive to write for release-to-release testing, because you should know what you changed, and what it affected (before you started). Relying on unit tests because you don't identify a change footprint is just band-aiding over a lack of understanding of the workings and machinery of your software. Initial development should be white-box tested and the developer should follow the parameters through the routine and confirm the result, IMHO.

    Where unit tests are really beneficial is when you want to test that your application works on other OS's / DB's. For example, it worked in Win XP with SQL 2000, does it work in Win 7 with SQL 2005? Changed compilers? Just run the tests, and you probably have a pretty good idea whether you have problem (assuming that you put the effort into creating tests that target the salient functionality).

    It's good to create high-level tests that test functionality. It's tedious and error prone to create a test for every member function of every object (as well as nearly impossible to maintain)

  • James (unregistered) in reply to Bim Job
    Bim Job:
    Or, and quite appropriately (I apologise for the top-quoting, although I have no earthly idea why I should do so):
    Bim Job:
    Mr. Wint: If at first you don't succeed Mr. Kidd...? Mr. Kidd: Try, try again, Mr. Wint.

    Courtesy of Diamonds are forever, here.

    Sorry to go off-topic but...

    ...that movie was a huge WTF.

    And I'm a "Sean Connery is the only James Bond" kind of fan. Something about that movie was just out out congruity with the other Saltzman/Broccoli/Connery Bond films.

  • (cs) in reply to frits
    frits:
    If not testing code is outlawed, only outlaws will not test their code.

    Nice one frits - but what if you're testing on an embedded platform with no filesystem, eh?

  • Someone like Kevin (unregistered) in reply to -
    -:
    300 devs? Is the company based in Sparta?
    FTW.
  • fjf (unregistered) in reply to method1
    method1:
    frits:
    If not testing code is outlawed, only outlaws will not test their code.

    Nice one frits - but what if you're testing on an embedded platform with no filesystem, eh?

    Then FILE_NOT_FOUND. Brillant, eh?

    Captcha: Frist

  • (cs) in reply to Befuddled

    <long rant>

    Uaggghahghghghgh!!! <claws eyes out!/><heads rotates 360 degrees/>

    Befuddled:
    300 developers == fail. Simple as that.

    Not everything is an enterprisey web thingie that can be written by half a dozen developers, even if they are stellar ones.

    How do you suppose then that things like Operating Systems or software that goes a Boeing 787 or an aircraft carrier (or things of that magnitude) get built?

    Obviously I'm using a lot of hyperbole in these counter examples (simply to bring the point across). However, there are a lot of types of systems (commercial and military) that cannot be written by anything less than hundreds of developers and testers.

    And in a large enterprise with multitude of systems, how do you expect them to handle all of the things they need to have to operate? With six programmers and whatever shinny programming thingie you think is the best thing in the history of computing?

    Take six of the better ones, and start building the next generation because all you have now is legacy.

    You say it as if "legacy" was some horrible thing.

    It is not.

    Work is work, and things need to be maintained to work. Any pristine and shinny web thingie that you just created becomes legacy the moment you are asked to make a change to it. You don't ditch your fully functioning car and buy a new one just because you want (or need) to update its stereo system, do you?

    It doesn't become legacy after a couple of tune ups, does it? You don't treat your investment (your car which is your tool and your financial investment) like that, so why do programmers insist in thinking of software (someones' custom-build tool and financial investment) in that manner?

    Moreover, anything non-trivial that you build is almost legacy before its first production deployment as you find that requirements change by necessity (as in "ZOMG! we lost 50% of our customers and now we have to integrate with this new customer who uses a complete different and arcane WTFesque exchange protocol, to be done like yesterday because if we don't the company is going to go belly up and all of us will be flipping burgers or making a line at the unemployment office".) Life doesn't stop for you to pigeonhole neatly for you to code and deliver.

    Moreover, developers (those who are professional) do not start writing new "next generation" systems just because they have an itch as in "OMG, this Java system is so kinda like yesterday. Let's rewrite the whole system in Groovy/Ruby/Boobie for no reason and let our employers pay the bill because it's Groovy/Ruby/Boobie".

    There needs to have a business reason for creating "next generation" fluff to replace otherwise fully-functional systems... what you pejoratively refer to as "legacy".

    Do your career (and the world) a favor and spend an hour listening to the following podcast:

    http://itc.conversationsnetwork.org/shows/detail3987.html

    </long rant>

  • (cs) in reply to RayMarron
    RayMarron:
    I don't think I could ever work somewhere that had three HUNDRED developers. How does anything ever get finished with so many hands in the pot? I can just imagine the multi-layer management WTFery.

    You will inevitably see some multi-layer management WTFery, but it is not as bad as some people think. Most people are divided in groups of half a dozen to a dozen (usually) working on their own thing (usually a specific system or subsystem.)

    The fun starts when all of them are working on the same large behemoth system. You still get your multitude of teams working on their own subsystems. Everything is going well, but then the WTFery starts during integration.

    These things are so huge that you can only do as much agile as you can in your own subsystems that more or less work a-okay. There is no way to have releases in anything less than 3 months (sometimes in anything less than a year).

    There is no way to integrate early and all the suckers have the same deadline. And as the day approaches, everybody is looking at each other thinking the same dreaded thought:

    How the blubbery fuck is all of this disparate shit going to even bootstrap, let alone work?

    But things eventually get to work, you learn some more and you go to the next fun phase of holy-craps.

    With a good company and an interesting project, there are nice things in working in small teams, and nice things in working with very large ones. People can learn a lot from either situation. It all comes down to getting what we put in and keeping a professional attitude of doing the best out of the situation.

  • Anonymous (unregistered) in reply to GCU Arbitrary
    GCU Arbitrary:
    I hope the developer responsible for checking in that unit test got reprimanded.

    A joke's a joke, fair enough, but where I come from we call those kinds of shenanigans "negligence", and persistant offenders get fired - you don't get to opt-out of good development practices simply because you don't feel like doing it.

    Where I come from, those sorts of shenanigans are encouraged. Persistent offenders get promoted to distinguished engineer. People discussing the issue with senior management are told that they're "too much of a perfectionist."

    No joke.

  • Anonymous (unregistered) in reply to the real wtf fool
    the real wtf fool:
    Seems to me that Ian didn't do a good job on selling the benefits to the devs. Making some real examples, showing how certain bugs that got through to test would have been caught...

    Unfortunately many people aren't rational.

    I have the misfortune of working with several PhDs one of which is in its first job outside a research organization and the other one who is not a software engineer.

    I've provided specific examples in code doing the same thing where the same sorts of bugs took 30 minutes to fix with good unit tests and 3 weeks to fix with no unit tests.

    They still don't write unit tests or modular code which is more readily validated.

  • Befuddled (unregistered)

    Luis, I'm not going to waste my time knocking down your out of context straw men.

    You've got a company with 300 developers doing Java. It's Java for crying out loud... it's almost harder to find Java people onshore who don't do TDD and Re-Factoring as a matter of course than it is to find those who do.

    Yet they've still managed to end up with a culture where developers don't see any value in automating unit testing. It's 2010 and they've not even discovered continuous integration until an external contractor shows it to them. I'd bet that they've not heard of design patterns or agile methodologies either. I expect they've got ISO9001 or CMMI and documents by the yard though...

    Random theories about the product being Windows or some sort of secret sauce for the military aside (and I've worked on two of the latter that were actually kept deliberately small and compartmentalized for security) the vastly more likely truth is that they have 300 developers because they have an increasing cost of change. They can't manage that with low level refactoring as they have no test coverage. If they are that dumb they haven't got automated acceptance tests that allow you to break the problem into reworking module by module. In other words they are in classic legacy trouble and will be offshoring to cost reduce soon if not already, and that is the death knell of any b2b product.

    The only way out is to start with a small team on the next generation product range using current best practise so that you can replace out existing customer systems before the cost of change strangles you.

    The clues are all there, yes I'm making sweeping generalisations, but I've worked for a variety of companies of all sizes across Europe and the US and I've yet to see a single shop of that size that proves them wrong.

    Small dev shops of 20 or so get more done at higher quality than giant Inc.s with hundreds. Sadly they get bought up and ruined but at least someone smart gets rich.

    There are barely a handful of places (google being one example) who look like they buck the trend and the reasons tend to be cultural and their ownership being more centrally held so that they are less influenced by the kind of traditional bottom line single year focused conservative management of the kind expected by PLC/Inc. shareholders and the fund managers that represent them.

  • FinanceNerd (unregistered) in reply to Befuddled
    Befuddled:
    CATS:
    Befuddled:
    If profit increased despite expenditure doubling income must have more than doubled...
    I may have confused the definitions of Profit and Income, but Wikipedia apparently agrees with me: http://en.wikipedia.org/wiki/Income_statement

    I specially quote: "income statement (as the name implies) takes several steps to find the bottom line, starting with the gross profit. It then calculates operating expenses and, when deducted from the gross profit, yields income from operations. "

    Yanks abusing English and wiki being wrong - shocker /shrug.

    Profit is income - expenditure.

    A little knowledge is a dangerous thing...

    [Gross] Income / Revenue less Cost of Goods Sold equals Gross Profit, which emphasizes the selling ability of the company. Gross Profit less Operating Expenses equals Income from Operations, which can be compared to other businesses in the same market. Income from Operations less Non-Operating Income (one-off proceeds from selling subsidiaries and the like) less Net Interest Expense less Taxes equals Net Profit (a.k.a. net income).

    You're welcome.

  • coyo (unregistered) in reply to dan
    dan:
    300 devs..... we don't need unit tests: This is Sparta

    feature!

  • anon (unregistered) in reply to Anonymous

    [quote user="Anonymous"][quote user="Befuddled"]300 developers == fail. Simple as that.[/quote] How many developers do you think work at Microsoft? I'm guessing more than 300 - or 3000

  • (cs)

    It's great to have unit testing for you code. But don't you need to have unit testing for your unit testing? And if you are going to be good about it, you will have to have unit testing setup for your unit testing testing.

  • (cs) in reply to dgvid
    dgvid:
    Maybe all that management gibberish about "buy-in" actually means something after all.
    They out source so many programming positions to India, we might as well do the same for management! Now if those wall street fat cats claim they need to have those billion dollar bonuses or they will quit, you just point them to India.
  • sino (unregistered) in reply to KP
    KP:
    The best way to get developers to test the code, either through automated tests, or whitebox/blackbox testing is to have them carry a support/on-call rotation.

    As soon as developers know that they are going to get a phone call at 2:30 AM (a time that would usually interrupt their WoW session;-), they will test the code.

    I personally don't find unit tests to be very useful or productive to write for release-to-release testing, because you should know what you changed, and what it affected (before you started). Relying on unit tests because you don't identify a change footprint is just band-aiding over a lack of understanding of the workings and machinery of your software. Initial development should be white-box tested and the developer should follow the parameters through the routine and confirm the result, IMHO.

    Where unit tests are really beneficial is when you want to test that your application works on other OS's / DB's. For example, it worked in Win XP with SQL 2000, does it work in Win 7 with SQL 2005? Changed compilers? Just run the tests, and you probably have a pretty good idea whether you have problem (assuming that you put the effort into creating tests that target the salient functionality).

    It's good to create high-level tests that test functionality. It's tedious and error prone to create a test for every member function of every object (as well as nearly impossible to maintain)

    Maintenance programmers and juniors that have no idea what the fuck you had in mind when you wrote what, you arrogant fuck.

  • StychoKiller (unregistered) in reply to Mr. Bob
    Mr. Bob:
    Bonuses? Design Specifications? What are these things you speak of?

    Yeah, it sounds amazingly like English!

  • Tom (unregistered)

    Geez, doesn't anyone here have any business sense?

    Testing is for the end user. Who else will know if it's doing what they want?

    Fixes? That's what future versions are for.

    Features? That's what upgrades are for.

    As long as the project is marketed properly, it will be a success.

  • (cs) in reply to Tom
    Tom:
    Geez, doesn't anyone here have any business sense?

    Testing is for the end user. Who else will know if it's doing what they want?

    Fixes? That's what future versions are for.

    Features? That's what upgrades are for.

    As long as the project is marketed properly, it will be a success.

    I'm a PC, and Windows 7 was my idea.

    FTFY

  • Peter B (unregistered)

    They don't teach programers like they used to. When I began in programming 20+ years ago a quarter of the coarse was dedicated to unit testing. Now I'm a senior test consultant it almost makes you cry. Next bugs found outside unit just send screen shot and description "It's not your job to debug!"

  • Drew E (unregistered) in reply to Peter B
    Peter B:
    They don't teach programers like they used to. When I began in programming 20+ years ago a quarter of the coarse was dedicated to unit testing. Now I'm a senior test consultant it almost makes you cry. Next bugs found outside unit just send screen shot and description "It's not your job to debug!"

    When I took Data Structures at CU Boulder the teaching assistants wrote unit tests and had a script which checked our code out of the revision control software and linked it against their unit tests.

    Students were largely graded based on how their implementations fared against the TA's reasonable complete unit tests.

    Ones who couldn't figure out how to code to an API, use make, or ensure their code worked failed until they got it right or found another major.

    Post-university, we found that the students who'd been through that class knew how to program.

    Unfortunately the university administration felt that the high failure rate (reportedly 1/3 of the class) reflected poorly on the instructor and stopped her teaching data structures.

    Graduate quality dropped markedly.

  • BAH (unregistered) in reply to GCU Arbitrary
    GCU Arbitrary:
    ... you don't get to opt-out of good development practices simply because you don't feel like doing it.

    Of course you do, if you're one of the VP's golden boys who can do no wrong. And if the consultant becomes sufficiently annoying with the kvetching, a simple word to the VP gets him fired.

  • X (unregistered)

    Disclaimer: I've been successfully using agile and testing for over a year.

    What I've found out is the TDD, BDD, Agile, etc are really religions. If you don't actually believe in them from the bottom of your heart they don't work.

    You can be taught the technique but you need to be converted into the testing religion of it to really work.

  • Dave G. (unregistered)

    I've had people try to sell me on unit tests before. I've heard all the alleged benefits of being able to effortlessly refactor your code because the tests will tell you if anything breaks, or of being able to see whether any new functionality causes regressions, all governed by the all-knowing unit tests that sit there as sentinels over your code.

    It's bollocks. It's theoretical hogwash. I have never seen a magical unit test that can be written once and serve its purpose in that form without requiring maintenance. When the application changes due to a change in requirements, or even just to a mild refactoring of the code, the unit tests have to change with them.

    And that's the rub. The unit tests themselves have to be maintained. That might seem fine at the start of a project, but once you have a load of unit tests on a project of sufficient maturity, you spend as much of your time maintaining the unit tests as the actual code!

    Eventually, timeline pressures force you to abandon the unit tests entirely because you just have NO TIME to keep maintaining them. You get unit tests deleted or commented out because you don't have time to dick around with them.

    In that case, you were better off not wasting the time writing the unit tests in the first place.

    Customers do not care about unit tests. They care about getting a working product, on time and on budget. You can argue all you like that unit tests help to deliver that, but in my experience they are worthless. They just weigh too heavily on your resources towards the end of the project. You have a deadline, a project to deliver, and you are running a business, not some undergrad crap in college.

    Unit tests do not work in the real world. In theoretical project world, your schedule would always be reasonable, and you would not be rushing at the end to cram in just-one-more-feature or fix some stupid issue that only occurs when they deploy it on Windows Server with service pack 1 with mcaffee version 5.4.33 and a pink elephant in the room. In reality, projects don't work that way. They never work that way.

    This article conveys my feelings better than I could. I encourage everyone who has either voluntarily drank the unit-testing kool-aid or had it rammed down their throats to read it.

    http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx

    I can think of a very few specific situations where you might want to use them, but my default is to reject them. Someone would have to prove to me, conclusively, why they would be good in a particular case, and explain to me why they won't become an unbearable burden at the end. I won't waste my time with them otherwise.

  • Shriike (unregistered) in reply to Befuddled
    If profit increased despite expenditure doubling income must have more than doubled...
    Sorry I gotta step in here real quick. They were talking about Gross Profit increasing (Revenue - Cost of Goods sold). So if Gross Profit has a small increase, but expenses double, then Net Profit will decrease.

    captcha paratus: It's a Latin bird.

  • (cs) in reply to Befuddled
    Befuddled:
    Luis, I'm not going to waste my time knocking down your out of context straw men.

    But you just did (???)

    Befuddled:
    You've got a company with 300 developers doing Java. It's Java for crying out loud...

    So what's your point?

    I'm currently working with a project of several hundred java developers, not counting systems engineers and mechanical engineers. Just because "it's java" doesn't mean it validates a generalization or that "it is a failure".

    Yes, and I know that some DoD projects are kept small because of strategic reasons. But not all such projects are the same (so I still fail to see your point.)

    Befuddled:
    it's almost harder to find Java people onshore who don't do TDD and Re-Factoring as a matter of course than it is to find those who do.

    ... and some more stuff...

    Still a generalization is a generalization.

    Befuddled:
    The clues are all there, yes I'm making sweeping generalisations

    Then why do you complain about my reply to your generalization? What else did you expect? As Chris Rock would say "whatcha want? a cookie?"

    Seriously, you don't want that type of reply, then don't generalize. Don't want your post to be called a silly generalization, then don't post a silly generalization. You seem like an intelligent individual, I'm certain you can elaborate you post better.

    Fragile e-motions aside, it is really that simple.

    After seeing your second reply (and the elaboration of your work experience), I don't doubt you know your shit, but it begs the question then why would you make a blanket generalization of the "300 developers = failure, run to the hills and away from the legacy" type in the first place.

    My response is perfect for THAT SPECIFIC post. You can try to paint my response to you as a strawman as well, or you can try to elaborate your point better next time.

  • Anonymous (unregistered)

    Unit tests find the kind of problems that people who are smart enough to write unit tests don't make.

  • GWO (unregistered)

    The Real WTF is that a consultant is paid a big stash of cash to introduce a new methodology, and get buy in from developers -- fails to do so, and fails to notice that this is his fault.

    If all the people in a swimming class drown, the instructor should get the blame. He can't just say "they were too stubborn to learn".

    Of course people have a tendency to be set in their ways.

    YOU'RE BEING PAID TO CHANGE THAT. DO YOUR DAMN JOB.

Leave a comment on “Unit Tested”

Log In or post as a guest

Replying to comment #301485:

« Return to Article