Let me guess, you don’t use source control either. Or unit testing?
[/quote]
You’d be guessing wrong.
[/quote]
Out of curiosity, what does “unit testing” mean to you? I would have said I unit tested my whole career, but now people do a lot of test-driven development, and use NUnit and similar tools. Standing in 2013, I say that what I did prior to 2004 wasn’t unit tested, although at the time I thought it was.
I’m not being hostile; this could be useful for you to know if you don’t.
ISO9000 was published in 1987. That is way newer than the stuff I was talking about. Over 20 years after OS 360, for one. The concept of development methodology had been established by then, for one thing.
In case you’re interested, to me, unit testing means inadequate testing for new features, and barely adequate testing of old ones. It gets the most use in regression testing, i.e. making sure new versions haven’t broken the old features. But other than as rudimentary test of functionality for new or old features it’s rarely done to the level necessary to find serious problems. When unit tests aren’t written by the original developer they at least aren’t just designed to always work. But as someone mentioned above, unless you engage in random testing of software you won’t catch any more errors than a diligent developer would have in the first place. But it’s no big deal, most companies just release software and let their customers do the testing for them.
(The previous opinion may be colored by a recent problem I had to uncover in a product that had passed through unit testing in several versions)
My company is just beginning to use this “scrum” thing, and to me, it seems like the exact thing we always did, with the added joy of daily status meetings.
But, this is apparently the thing of the future, so I’ll play the game instead of asking “who moved my cheese”? The skills required are no different from the skills required before.
At the very least, I have a renewed appreciation for the fact that rugby is not America’s National Pasttime.
Actually it means no testing of features at all. That’s not what unit testing is for. It tests units of code (usually methods) in isolation to verify that they do what they’re supposed to do. When you have 100% unit test coverage and 100% of them are passing, you haven’t even begun the QA process yet.
Of course, this is a common misunderstanding, and you’ll frequently see people writing full-fledged feature tests in JUnit, but writing it in JUnit and running it after every commit doesn’t make it a unit test.
Apparently you don’t know where features come from. No matter how you slice it, unit testing only tests isolated sections of code, and it’s essentially a waste of time if you have an adequate QA process. It’s most commonly used as an excuse for not having an adequate QA process, so it’s worse than no testing at all because it provides a false sense of security.
Oh gee, could it possibly be from methods? Could I possibly avoid wasting the time of a build, deployment, and QA test cycle by probing for fundamental errors by the unit level before I even commit the code? Nah, that’s way too easy. QA testers are a dime a dozen, let those guys catch runtime type errors that could have been easily been detected on the developer’s desktop.
This knife is really crappy at loosening screws , therefore knives are useless and cutting is a waste of time.
I’m truly sorry you work in a place where this is a problem, and I’m here to tell you that better jobs are out there.
Well this is odd because I thought having both unit testing and a good QA process provides the best solution.
One of my contractors is a huge TDD advocate and trying to get us to use it more here, I can see the advantages but not sure the overhead is worth it. He is using it in his latest project and the developer he is pairing with, one of my best, is becoming a convert so I may take a serious look at it.
There is a cost associated with automated unit tests. There is a risk of greatly multiplying that cost if the process isn’t overseen by experienced developers who understand the purpose of unit testing, because unlike a manual test executed by a QA analyst, there’s less opportunity for a human to say “this test adds no value and I’m not wasting my time with it.”
That is a risk and I certainly wouldn’t deny it. But the first time you inherit a hundred thousand lines of code that needs broad changes in a short amount of times, you will thank your lucky stars if the previous team covered it with tests to cover that niche between what the compiler catches and between what a QA team catches in integration test after the code is committed and built.
And that’s not even touching on the practice of emergent design. That’s a good practice that depends on unit testing, but you should think about it distinctly from unit testing.
You have no idea what unit testing is for, do you?
Unit testing is your safety net. It’s the thing that tells you your methods actually do what they are supposed to, and that lets you refactor your code safely. It’s not about whether the code as a whole does what it’s supposed to - that’s the realm of functional testing, which you should also automate.
Unit tests are not “worse than no testing” they are critical to professional software development. They’re part of your codebase, and they run every time you check code in.
davidm, if you check back:
One of the things I look for when hiring developers is their level of awareness of the state of the profession. Most of our questions are cultural; we do a coding exercise, but it’s only 10-15 minutes of an hour interview, and is done on a whiteboard in the language of the interviewee’s choosing.
We ask about how you stay current in your field, about your attitudes towards pair programming, about your familiarity with a set of languages, about which Design Patterns you’ve used and how that was successful or unsuccessful.
What we’re really trying to do, in the multi-billion-dollar ecommerce company where I work, is find people who are going to be able to learn and adapt rapidly. We use agile, mostly XP with some Scrum, although for the most part our teams are skeptical of Scrum, given the amount of jargon and process-over-meaning that it’s acquired.
Some of our recommended books for developers:
UML Distilled, Fowler
The Pragmatic Programmer, Hunt & Thomas
Clean Code, Martin
Design Patterns, Gamma, Helm, Johnson & Vlissides (the Gang of Four book)
The Principles of Product Development Flow, Reinertsen
Extreme Programming Explained, Beck
Lean Software Development, Poppendieck & Poppendieck
Working Effectively with Legacy Code, Feathers
Release It!, Nygard
Growing Object-Oriented Software Guided By Tests, Freeman & Pryce
It sounds like you’ve been largely working in an agile manner without realizing it. I was in the same boat; I started working agile in 2001, but did not realize that was the label for what I was doing until 2008.
I think you can adapt to this really quickly - the thing I would stress is that while you haven’t been exposed to these specific terms, the underlying concepts are ones that you embrace. Because I suspect that you do.
He most effusive about it due to a recent refactoring. The code is a quite complicated engine for calculating figures (Client Rebates basically), the arithmetic is straight forward though it involves a lot of variables. They recently decided to refactor the calculation engine due to breaking the SRP in too many places and, as he put it (roughly), “After 4 hours of moving code about and redesigning it with one click of run all tests I was confident my code was correct”
Now for this sort of thing, calculating numbers where you know exactly what the answer should be for given inputs, I can see the advantages. For code that doesn’t involve calculations I am yet to be sold, I need to investigate more though.
Simple way to find out. Do you keep track of the bugs caught at all levels of test? Do you have an idea of the cost of catching a bug at QA vs. catching it earlier? It sounds like you have an idea of the unit test cost. If you can collect all this information, you can easily decide whether unit testing is worth it.
Clearly, if developers never insert bugs that are caught by unit testing it isn’t worth it, but if they consistently insert 10 bugs a module it probably is. No one can give you one answer for all shops.
Other reasons I think unit tests are useful:
-Probably more than half of exceptions I’ve seen in my career were null refs. Unit testing (at least in my experience) makes the developer consider the situation of what to do with empty or null data ahead of time. Null ref occurrences go down considerably.
-When your code base is large and complicated, it’s easy to break somebody else’s code without realizing it. You sort a list differently for your purpose, and somebody else who was counting on the first record having some property gets screwed. Unless s/he wrote a unit test for it. If your code change broke some unit test, you know immediately it must have been something you did.
Actually, no - it wouldn’t. The issue is not whether you use the methodology, but whether you are familiar with it. And I advocated becoming familiar with it.
But the reality is that it’s all buzzword nonsense. POLA, KANBAN, PRISM, SCRUM…it’s whatever is popular today. I’ve worked with too many of these methodologies; they come and they go.
Even though I make my living programming, I can tell from this thread that I am completely unsuitable for a corporate existence. I turned down a well-paying corporate job 20 years ago when I was fresh out of college and instead went with a small business. I have no complaints but if I ever quit what I’m doing, I guess I’ll go work at WalMart or do independent consulting.
I don’t think that’s true; there is a real substantive difference between waterfall and agile. I’ve worked in both methodologies in big companies and startups, and even brought some development teams between the two. Not all engineers or organizations can thrive in both of them.
And regardless if they change over time, you need to be able to follow the methodology that your particular organization is using right now. I agree that having several tool sets in your quiver is the best approach for a software engineer.