Comment On Unit Tested

Hey, testing the equality operator is important. You can't get ANYTHING done without that.

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.

I will soon have the same task of introducing our development team to test-driven development. I really hope that I won't make the same experience.

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.

Continuous Integration Server emails != teeth.

The generated emails were just noise, which was eliminated in a short, effective manner (savvy developers strive for efficiency, do they not).

An addition to the job description for devs and managers, a line item percentage of developer bonus tied to automated testing review during annual reviews, and a line item percentage in the manager bonus dependent on the staff automated testing performance == teeth.

CAPTCHA - augue - The devs would augue about it all day long, but we finally made them use automated testing.

Oh, that's painful. Someone really just didn't get the whole damn point of testing, and instead are thinking it is just something done to placate management. Public humiliation (well, within the workplace) is probably the best way forward to remind these people that they're making life hell for their colleagues and customers.

OTOH, it does expose an issue in JUnit, in that it makes it too easy to do this sort of thing. I prefer testing frameworks where the check of the result value is not inside the test code, but rather outside it as that encourages people to at least check what the results are. Doesn't stop evil idiots though, and part of the issues with JUnit are really that it's working with Java. Other compiled languages have similar problems; they're all just not that easy to test. You're far better off doing your integration and building your testing fabric in a scripting language. (In fact, that even gives you an opportunity to deal with the “programmers don't do testing” folks; have them write components that people who actually understand the purpose of testing can integrate.)

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.

Three hundred developers, sure, but they aren't all necessarily working on the same project. Where I work, we have fifty or so developers, but no more than 2-4 on any given project most of the time.

Unfortunately that exmple is not (much) worse than what I see in unit test code on a regular basis.

"# of Tests" and "% Code Coverage" are poor metrics for measuring test effectiveness.

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!

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!

Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.

"The developers stubbornly held that testers should test code, not them."

My employer found an interesting way to address that problem. Stop having testers test code. Interestingly enough, that has not brought the expected benefits...

peterbruells:

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!

Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.

You're close, bonuses should be tied to the manager's necks AND tied to the absolute value of gross profit. If the value of gross profit should fall like a brick, then the management should fall with it.

peterbruells:

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!

Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.

Agreed. That way managers can receive a nice extra because of the rise in gross profit, even though expenses escalated twice as much in the same period.

Maybe all that management gibberish about "buy-in" actually means something after all.

IMHO, developers test code, testers test functionality.

As a developer, I hate putting stuff in Test that breaks with compile errors (Classic ASP...) the first time someone tries to test it. It delays the test tract because I need to recode that section and request a new transport. Because I feel personally responsible for this kind of thing, I test my code (to see if the scripts don't crash). No automatic systems, just professional honor.

It's for the testers to determine if they got what they wanted.

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.

If not testing code is outlawed, only outlaws will not test their code.

peterbruells:

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!

Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.

And presumably by absolute value you mean:
abs(profit)
so they will always get a bonus as long as the profit is not zero.

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

SCB:

peterbruells:

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!

Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.

And presumably by absolute value you mean:
abs(profit)
so they will always get a bonus as long as the profit is not zero.

Which is what probably should have clued you in to the sarcastic nature of peter's comment.

If profit increased despite expenditure doubling income must have more than doubled...

Anyway.

300 developers == fail. Simple as that.

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

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

This is a very good point. If you swan into an office and proclaim that everyone now has to start writing unit tests, it comes across as additional work and nobody in their right mind wants that. But if you can demonstrate the fact that life becomes easier with an effective suite of unit tests, people begin to realise that a little up-front work can pay off in the long run. You have to sell it right if you want people to buy into it.

steenbergh:

IMHO, developers test code, testers test functionality.

Quoted for truth!

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 like unit testing and TDD as much as the next guy, but there's just no way you're going to convince hundreds of developers to adopt those concepts when there's already a (presumably) massive codebase.

Reliable unit testing requires clean interfaces and abstractions over things like file systems and databases. Even if you were sold on the idea of unit tests, it's a pretty monumental task to go back, eliminate singletons, get rid of static methods, use dependency injection, etc. Especially if you've never written unit tests before. Even new code can be hard to test if you're forced to write it within the confines of an existing crappy framework.

There are ways to wrestle with legacy code and get it up to snuff (see Working Effectively with Legacy Code [Feathers]), but it's not easy and would take a smart, dedicated person to direct such an effort. I don't think the submitter of this WTF is up to the task.

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.

Not at all. The developer's tests should 100% verify that the implementation (Code) matchs the Design Specifications. The tester's make sure that the product meets the Business (aka User)requirements.

If Test Drive Development is followed, then failures discovered by the testers SHOULD be the result of a failur to properly specify the requirements to the Developers, and NOT because of "mistakes" made by the developers.

Of course, all of the paties are (hopefully) human, so various mistakes WILL occur, but they should be the exception rather than the rule.

CAPTCHA: erat...the location of the error....

300 devs? Is the company based in Sparta?

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.

You won't put them out of work. It's a testers job to make sure that functionality both works and conforms to the specification. Even with 100% code coverage (and something like Selenium) you'll won't be able to automate the specification testing. At least where I work, the testers have enough to deal with without worrying about code level errors in my code (they do have to deal with my implementation level and design level issues)... Making their lives easier helps make mine easier (I get EXCELENT error reports and breakdowns of any kind of failure)...

It's not about putting them out of a job, it's about making them more effective at the job they are supposed to do. If right now, they are spending 50% of their time dealing with code level issues, then they are not spending 50% of their time dealing with issues that they should be dealing with...

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

Exactly this ^. Instead of effectively selling the idea of unit testing he instead went with a passive aggressive system of sending out nag e-mails (to everybody) which only breeds resentment and anger.
We have a similar problem with a system for booking time on projects. Rather than sell us on it or, god forbid, make it work in a way that actually reflects what we really do or maybe replace it with a system that doesn't take several seconds just to move from one cell to another, our portfolio manager instead sends out nagging e-mails to everybody naming who hasn't booked their time.

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

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.

steenbergh:

IMHO, developers test code, testers test functionality.

As a developer, I hate putting stuff in Test that breaks with compile errors (Classic ASP...) the first time someone tries to test it. It delays the test tract because I need to recode that section and request a new transport. Because I feel personally responsible for this kind of thing, I test my code (to see if the scripts don't crash). No automatic systems, just professional honor.

It's for the testers to determine if they got what they wanted.

Yep, sounds like a Classic ASP developer.

Unit test != functional test or integration test. What we as testers are looking for is not what you as developers are looking for, and testing your code will NOT put us out of a job. Au contraire. It will make my job EASIER, because I will be able to actually look at functionality and not at compile errors.

In a nutshell - you should be asking "does the code do what it's supposed to do, and is it compliant with the development spec?" I will be asking "does it not do what it's NOT supposed to do, does it play nicely with the other pieces we've got, does it fail gracefully when it doesn't work for whatever reason, and does it fulfill the business case?"

Plenty there without having to catch errors the developer should have fixed before I even got it.

Many years ago I worked with researchers who experimented with "Fault Injection" -- they would intentionally insert errors into (copies of) the code to see if the test suites would pick up the problems.

It was all automated and ran 24x7 for bazillions of time, but they were getting really good at making strong test suites.

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 this makes the assumption that the developers actually care. Mine certainly don't (I'm on the test team).

And this isn't general "QA bashing dev" -- I've worked with lots of great developers who do care and those are the days that I enjoy my job as a tester. These guys actively and passionately do not care -- to the point I would use the term sabotage (which it may be -- IT management is very much unliked).

Anonymous:

They're the only female staff members we've got

Are you sure you know what they're testing about you?

...after many, many tutorial sessions with developers, and quite a few long meetings spent trying to convince them of the benefits, no tests emerged. The developers stubbornly held that testers should test code, not them.

I agre with previous commentors that the author should have done a better job selling the new scheme to the developers. Unit testing is a means to an end, it makes development faster, easier, less frustrating and more fun, otherwise it's just Yet Another Fad Shoved Down Our Throats By Management.

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.

Befuddled:

If profit increased despite expenditure doubling income must have more than doubled...

Anyway.

300 developers == fail. Simple as that.

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

And make sure that's 3 females and 3 males, get them on the ark and wait for the deluge.

I'm also about to undergo the same process. Hoping to add TDD and CI at a company that doesn't do either. Should be fun.

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.

Bonuses? Design Specifications?
What are these things you speak of?

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.

Don't be too hard on him - he's probably never had more than two or three classmates on his team projects.

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.

A classic (read it until the end, I admit it is a bit harsh but the author's got some interesting points)
http://www.wilshipley.com/blog/2005/09/unit-testing-is-teh-suck-urr.html

TheCPUWizard:

Unfortunately that exmple is not (much) worse than what I see in unit test code on a regular basis.

"# of Tests" and "% Code Coverage" are poor metrics for measuring test effectiveness.

Please explan how the test Code would increase Code coverage.

A sufficiently high coverage certainly is not sufficient for an effective suite of tests, but is certainly necessary so it is hardly irrelevant...

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

JoeB:

Befuddled:

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

And make sure that's 3 females and 3 males, get them on the ark and wait for the deluge.

The female developers are a good idea -- and they're an endangered species anyway -- but male developers don't often mate successfully. Besides, if you put two male nerds in the same ark in the presence of females, they'll kill each other. Male scientists might be able to coexist, but don't include physicists or you'll get genetic narrowing due to the Feynman effect.

300 devs..... we don't need unit tests: This is Sparta

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.

http://thedailywtf.com/Articles/The-Defect-Black-Market.aspx
Need I say more?

Six months and three hundred developers? I recently worked with a team of *six* developers, all of whom were quite clueful and pleasant to work with, as well as being generally open to new ideas, and it took me at least a year to really 'sell' them on doing unit tests (not even full TDD, just paying enough attention to code coverage and corner case testing for it to be useful, and doing so in parallel with the initial coding).

And that was a year of me cheerleading, making sure my own code was tested as thoroughly as possible, and taking personal time to work with the other developers and help them write tests, as well as mentoring them in how to *think* about putting together a test suite so that it would actually do useful testing.

Unit testing, whether done as part of TDD or not, isn't something you can push down from on high, no matter what you tie it to. It has to come from the ground up, and the only realistic way to get it, from a management perspective, is to do what you can to ensure that it is liberally 'seeded'.