- 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
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.
Admin
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.
Admin
Admin
Admin
Isn't that where the horse is supposed to go?
Admin
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.
Admin
Admin
Mr. Wint: If at first you don't succeed Mr. Kidd...? Mr. Kidd: Try, try again, Mr. Wint.
Courtesy of Diamonds are forever, here.
Admin
Or, and quite appropriately (I apologise for the top-quoting, although I have no earthly idea why I should do so):
Admin
Clearly this post wasn't unit tested.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
Admin
Admin
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
Admin
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.
Yanks abusing English and wiki being wrong - shocker /shrug.
Profit is income - expenditure.
Admin
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.
Admin
Admin
Admin
Admin
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)
Admin
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.
Admin
Nice one frits - but what if you're testing on an embedded platform with no filesystem, eh?
Admin
Admin
Captcha: Frist
Admin
<long rant>
Uaggghahghghghgh!!! <claws eyes out!/><heads rotates 360 degrees/>
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?
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>
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
[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.
Admin
feature!
Admin
[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
Admin
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.
Admin
Admin
Admin
Yeah, it sounds amazingly like English!
Admin
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.
Admin
Admin
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!"
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
captcha paratus: It's a Latin bird.
Admin
But you just did (???)
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.)
Still a generalization is a generalization.
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.
Admin
Unit tests find the kind of problems that people who are smart enough to write unit tests don't make.
Admin
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.