- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Hey, testing the equality operator is important. You can't get ANYTHING done without that.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.)
Admin
Admin
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.
Admin
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!
Admin
Yeah. Bonuses should be restricted to management and get tied o the absolute valute of the gross profit.
Admin
Admin
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.
Admin
Admin
Maybe all that management gibberish about "buy-in" actually means something after all.
Admin
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.
Admin
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.
Admin
If not testing code is outlawed, only outlaws will not test their code.
Admin
Admin
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...
Admin
Admin
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.
Admin
Admin
Quoted for truth!
Admin
Admin
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.
Admin
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....
Admin
300 devs? Is the company based in Sparta?
Admin
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...
Admin
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.
Admin
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. "
Admin
Admin
Yep, sounds like a Classic ASP developer.
Admin
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.
Admin
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.
Admin
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).
Admin
Admin
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.
Admin
And make sure that's 3 females and 3 males, get them on the ark and wait for the deluge.
Admin
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.
Admin
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.
Admin
Bonuses? Design Specifications? What are these things you speak of?
Admin
Don't be too hard on him - he's probably never had more than two or three classmates on his team projects.
Admin
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.
Admin
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
Admin
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...
Admin
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".
Admin
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.
Admin
300 devs..... we don't need unit tests: This is Sparta
Admin
Admin
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'.