Software Development optimize

Poll: How important are unit tests to you?

Justin James thinks the usefulness of unit tests is often overstated, and that unit tests aren't necessarily mandatory for all developers. Are unit tests important in your development work?

Unit testing is a development practice that is viewed as a "must do" by more and more programmers and experts. And yet, I think that unit testing is much less mandatory on smaller teams, non-API/framework development, and for certain types of code (anything non-deterministic comes to mind).

I'm not saying that unit tests are unimportant or useless, but I do think that their usefulness is often overstated, and that they have differing levels of utility to different developers.

J.Ja

More about unit tests on TechRepublic

About

Justin James is the Lead Architect for Conigent.

21 comments
jefferyp2100
jefferyp2100

The correct answer *should* be "very important." The real answer is "we don't use them because our company doesn't think they are worthwhile." Seriously.

wkenjackson
wkenjackson

I feel that unit tests are very important because they make individual developers and especially teams, even small ones, more productive. The best and most productive developers that I've worked with have all done unit testing. But...the unit tests weren't and don't have to be completely automated. The key thing is to do some development then unit test that part to get it working before moving on to other areas or on to integrating your work with others. For automated tests, functional tests are often more important and worthwhile than unit tests because they help to verify behavior from the business perspective and can be used in regression testing.

sysop-dr
sysop-dr

Depends on the job. A javascript/ajax web app, no, a saftey related engineering code, required. Just be smart about it and learn to put the proper QA at the level required (or not) for the project.

TrueDinosaur
TrueDinosaur

An application should not leave the programmer?s machine if it fails basic testing. Like required fields (as defined by specifications) allowed being empty. Date fields that accept 02/29/2011, 09/31/2010, etc. Numeric fields that accept letters and/or special characters. Text fields that cause SQL to barf if a ? is entered. A QA team should not be finding these types of errors. To me, an old COBOL fart, the above should not happen but I see it in my shop all the time. It should fall under a Programming Standards umbrella and be part of a person?s annual job review.

bklau2006
bklau2006

IMO, unit tests was popularized by the Agile movement. The Agile movement was mostly initiated by consulting companies who oversold agile to management who would hear anything to boost productivity and shorten delivery cycle. After all consulting companies gain gig on Agile training and consulting. Let's get real. Customers do not care nor see unit tests or other SDLC byproducts besides the softwares they installed or use. Is unit test bad?. Not at all. They are most appropriate for public API or inter-component development. But like any other stuff in life, their use and benefits can be a misfit or exaggerated in some situations. Unit tests needs to be written and maintain. They are sibling softwares by themselves. They could take up as much effort and time developing the target software themselves. One thing is ROI with respective to defect discovery can reach a saturation point. Second, a perfectly "passed green" conveys a false sense of security. IMO, unit tests should be viewed as a "fine granularity" smoketest or regression tests. Use it where its approriate and don't lose sleep over situations where ROI is not worth it.

Ron_007
Ron_007

Sorry, I can't agree. Even for scripts and batch files you have to "unit test" them to make sure they do what you expect. It is a simple matter of economics. Do you "waste" the time of the lowest paid person on the team, the programmer/developer, doing unit tests or do you waste the time of the analysts and clients finding simple coding errors. The last time I ran into someone who didn't unit test was a team of contract programmers we hired for Y2K coding. It was a PITA. I never could pin down the current status of the project because the programmers would pass me code that they had "finished". But way to often it wouldn't even COMPILE!, let alone run correctly. I would have to walk through the code to find the error and send it back to them to fix. Very annoying and time wasting. My boss was constantly breathing down my neck because project status was constantly changing, progress and "retrogress". Granted on small tasks or small teams, "unit testing" may merge into higher level "acceptance" testing, but it is still there.

Tony Hopkinson
Tony Hopkinson

Wizards tend to go for public members of a class of a class for instance, which given the amount of scaffolding we can be forced into turns into onerous.. Poor tests don't help, designing so you can test always does. It makes you code properly in self defence. We try to set things up through separation of concerns so we can execute big blocks of the code with testfiles. If that fails then we run what unit tests we have and try to beef them up, on the basis that they should have been run before check in. When/ if we ever get to TFS 2010, we are looking forward to gated checkin and some 'moral' authority for the resource to build up our tests. Just telling the boss it's a good idea hasn't worked, may be a number of failure reports will give us the ammo.

apotheon
apotheon

There seems to be a fairly substantial gap between people who think that unit tests are mandatory at all times and the next popular step down -- which lands somewhere in the realm where your article seems to live, Justin. I fit into an in-between zone, where unit tests are an important part of development about 98% of the time, when working on anything bigger than a glorified shell script. In short, if the program requires maintenance, it should have unit tests. Even for nondeterministic code, such as producing a random number between five and fifty (for instance), unit tests can help identify Heisenbugs like values that occasionally stray outside of that range or behavior that might produce unexpected data types. Overestimating the importance of unit testing can cause problems, of course -- potentially slowing down development or unnecessarily constraining the exploratory aspects of the development process. On the other hand, underestimating the importance of testing can have dire consequences. My attitude is: when in doubt, test it. In fact, the methodologies of test driven development can help encourage modularity and simplicity of program design, which is something that should be a high priority for pretty much any software developer.

HAL 9000
HAL 9000

If you don't test it you can say it's perfect. Also if you do test but not monitor the test you can say that it's perfect. By monitoring any Testing all that does is prove that the system is not perfect. ;) Col

apotheon
apotheon

> A javascript/ajax web app, no Why not?

Tony Hopkinson
Tony Hopkinson

What if the web app was managing your bank account? If you work for abank, you need not reply, they already have several times. :( Good unit tests and more particularly designing so you can, kills potential errors and highlights ommisions and contradictions in the requirements before you write a line of code. If they merely discovered where you had gone wrong, they would be little better than paying a human tester to click on every button.

Tony Hopkinson
Tony Hopkinson

To unit test effectively you have to do modular designs and keep separation of concerns. That means your validations should be in the code that holds the entity not the UI. It also means you don't fall into the trap of using say a date component which won't accept a bad date, so your design only 'works' with a UI. If a field is mandatory, then it should have n atribute that says so. The ui can then use that as a quick validation, and the code can use it to make sure you didn't forget to set the UI up right. Unfortunately this sort of thing fell by the wayside during the RAD craze and retro fitting it is an effective rewrite. This was a big case of development shooting itself in the foot, technical incompetents in management asking us to do so is neither here nor there.

Tony Hopkinson
Tony Hopkinson

you engineer the software so you can unit test accurately if you need to. Retrofitting it, is a nightmare. Try doing it in an unrefactored legacy code base, where separation of concerns has been jettisoned for the immediate gains of a monolithic architecture. You'll be cussing for a long and unproductive time. As for agile inventing unit tests, not true. Main frame batch processes were inherrently testable because of the modular design. Unit tests came back in to fashion because of the abortion that was RAD, which encouraged about every bad design practice you could think of.

bergenfx
bergenfx

Object level testing, (you mentioned classes, for "instance)." I don't think we had the discipline down, as much as the idea, but at one venture we "committed" to writing test driver methods for classes, so when a modification was made, the test methods could be run to ensure nothing was broken. It's pretty rigorous software engineering, but if you are developing large scale, lasting systems certainly worth it. And then, off-thread ... I have been wondering for awhile now what your avatar was. Finally, convinced it was a vulturized penguin, I zoomed in ... and it's not. So, never mind, I won't sic the linux community on you.

Jaqui
Jaqui

"My attitude is: when in doubt, test it." needs to be My attitude is: test it. :D

Sterling chip Camden
Sterling chip Camden

"if the program requires maintenance, it should have unit tests." Most of what I work on applies to many users at vastly different sites. I constantly code to a software contract, and unit tests prove compliance with that contract. I've found that if you don't write unit tests, there are always a surprising number of cases in which you thought you were fulfilling the contract, but you missed it. Another name for those cases: bugs.

Tony Hopkinson
Tony Hopkinson

But I don't the like teh shotgun method blast of test wizards. If you've gone wrong in property accessor for instance, it will almost certainly show up where that property is used. We actually get more out of .Nets code quality rules and pre and post condition asserts than we do 'low level unit tests. In an ideal world I'd test every thing I could, as it is I have no choice but to target areas where mistakes are more likely to happen.

apotheon
apotheon

Do you think I'm saying "when in doubt about the code"? I'm saying "when in doubt about whether to test it". While one should probably test more than when most people are in doubt, I think that piece of advice will tend to lead to enough testing. As people use unit tests in cases where they are in doubt, they will realize benefits from that, and gradually start to question other cases where they were certain they did not need to use unit tests. Meanwhile, just telling people to test everything all the time is likely to get people to ignore me -- and, frankly, there are times that unit testing is unnecessary, such as this: perl -le 'while() { print }' filename.txt