Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Pragmatic JUnit Testing

timothy posted more than 10 years ago | from the better-than-sex dept.

Programming 118

Will Gwaltney writes "The Pragmatic Programmers have done it again. This time it's with volume 2 of their Pragmatic Starter Kit series, Pragmatic Unit Testing in Java with JUnit. In the friendly, accessible style we've come to expect from Andy Hunt and Dave Thomas, the book provides a gentle introduction to unit testing in general and the JUnit testing package in particular. Of course, by the time you've read through the introduction you're hooked, at which point Andy and Dave give you enough information to make you not just a good unit tester, but a better developer to boot." Gwaltney offers this disclaimer: "I know both authors and was one of the proofreaders for this book. I have no financial stake in either the book or their company." With that grain of salt, read on for the rest.

What's the Approach?

You can go a long way in the unit testing world with this book. It's a great starter guide for learning about unit testing; the first chapter has several small sections which answer many of the questions a novice might have about the subject, including some of the most common objections to unit testing. Then the book launches into a detailed user guide to the JUnit package, including some useful but lesser-known topics like writing your own custom asserts.

After you've got the basics down, the book spends several chapters drilling into the concepts, considerations, and best practices for writing good tests. This section of the book is quite practical, and is where the true worth of the book comes out. Any developer who reads this section will come away better for it even if they never consistently write unit tests. It's amazing how many testing issues turn out to be development issues at their core; this section of the book points some of them out. Simply being aware of these issues can help you to avoid a number of common pitfalls.

Finally, the book discusses common unit testing problems and their solutions. This section is a lot of fun because of the anecdotes that Andy and Dave include; unfortunately some of them I recognized from my own experiences as a developer. (What, me do that? No, uh, of course not!)

Who's it For?

This book is primarily for developers (and testers who are intimately involved in the development process), since unit testing per se is primarily a developer task. Depending on the organization of the software shop, by the time code gets to a formal testing or QA group it's probably too late to apply unit testing methods effectively. (Note I said unit testing methods here.) The book is ideal for the unit testing novice, and there's a lot of good information here for more advanced developers to ponder.

The book is targeted at those who want to learn "how to think about tests, how testing affects design, and how to handle certain team-wide issues you may be having" (from the Preface). In particular the book is an excellent source of information for those developers who have recently moved into the Java area and are looking for a good testing framework.

No matter what your role in the development process, this book can help give you a fresh perspective into unit testing and related issues. It prods you to think about issues that perhaps you hadn't considered before.

Pros

As you can probably tell, I like the Pragmatic Programmer writing style. It's informal and friendly without being chatty or wordy, and the main text moves along well. More technical discussions are reserved for sidebars, and there are "Joe Asks..." sections throughout the book that anticipate questions that Joe Programmer might ask about the current topic.

The examples in the book are excellent. Many books err on the side of code snippets that don't have enough context to be understandable, or multi-page code extravaganzas that bury the details of the topic at hand under mountains of cruft. I found the examples here to give just the right amount of detail to understand what's going on. And the source for all the examples is available from the author's web site.

Cons

What this book is not is a reference manual for JUnit. The book doesn't include a javadoc listing for the JUnit package, nor does it have a section that digs into JUnit's internals. This is not necessarily a Bad Thing because that information is available from the JUnit web site, but it does bear mentioning.

If there was anything I found to complain about it was the use of acronyms in the concepts section of the book. I'll admit right here that I'm no lover of acronyms, so I felt that using things like Right-BICEP, CONNECT, and A-TRIP as mnemonics for the concepts was a bit over the top. (Read the book to see what I mean.) However, I have to admit that they help me remember the concepts discussed, so I guess they do their job (grumble).

Why Should I Read this Book?

If you hate testing, this book will very probably change your mind, and you'll have fun in the process (the stories are great!). And even if you still hate testing after you've finished the book, you will have enhanced your development skills enough to be able to delude yourself that testing isn't necessary for you (well, maybe not that much). At the very least, this book will make you aware of the various issues that proper testing can expose and maybe help you try to avoid them. By shining a light into these areas, it can still make you a more effective developer... maybe effective enough to realize how much more solid your work could be with this type of testing coverage.

If you love testing, this book will remind you why you began the love affair. Your love will be strengthened and deepened, and the tests you write will undoubtedly get better, too.

For Java developers specifically, this book will get you started writing JUnit tests painlessly and effectively and will take you a long way down the road to unit test proficiency. It will give developers in any language quite a bit to take "back to the terminal" regarding design and process as well as testing. An excellent and much needed book.


Like volume 1 of the Pragmatic Starter Kit series ( Slashdot Review), this book is available from the Pragmatic Programmer website. The printed version is $29.95 and there's a PDF version available for $20.00. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

118 comments

Sorry! There are no comments related to the filter you selected.

Pragmatic? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8432836)

Slashcode uses FAG-matic testing.

Thanks for listening to this first post attempt.

HELP! I HAVE CRABS IN MY ANUS! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432898)

HELP! A DINGO STOLE MY BABY! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8433007)

I "test my unit" several times a day!

huh (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8433126)

junk characters? what the fuck is your problem? are you some sort of character bigot? i mean, really. what the fuck is wrong with - and ( and all their friends? are they somehow inferior to e and a and such? do you hate niggers, boy? is that your goddamned problem?

Re:Pragmatic? (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8433170)

I don't fuck around, comprende?!

I'm just too fucking drunk to post anything sensible but I just wish to register my personal hatred towards following people:

1) Skinheads.
2) Mexicans.
3) Ass-spelunkers.

In fact, I hate the ass-spelunkers most.

Ass-spelunker? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8433283)

What the fuck is an "ass-spelunker"?

JAVA (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432837)

IS FOR FAGETS.

I've read both books (2, Informative)

Pingular (670773) | more than 10 years ago | (#8432842)

and I prefer this [amazon.com] one. Just my opinion though.

Re:I've read both books (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432867)

No one cares for your stupid opinion, Sir Whacksalot.

Re:I've read both books (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432869)

You have read neither. You just posted the first book on java unit testing you could find on amazon.

YOU ARE WORTHLESS SHIT (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8432992)

Moderators, express your consent by modding this offtopic

Oh yeah? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432849)

What's so damn pragmatic about it? FP

That Grain's A Boulder (4, Insightful)

tomblackwell (6196) | more than 10 years ago | (#8432864)

It might be wiser to trust someone slightly more removed from the creators and creation of this book with respect to its utility.

Re:That Grain's A Boulder (4, Insightful)

happyfrogcow (708359) | more than 10 years ago | (#8432948)

i think you're blowing it a bit out of proportion. the review clearly stated pros/cons/intended audience and more.

would you take a beta-testers review of an online game different? I bet you would be glad to have the behind the scenes insight as to whether or not the game sucks. If you were smart you would do just as was said and "take it with a grain of salt". continue to look for other reviews and file this one away in your head for later.

Re:That Grain's A Boulder (2, Funny)

Short Circuit (52384) | more than 10 years ago | (#8433579)

At the end there, I began expecting to have children with my testing software. (I'm certainly not likely to have children any other way...)

Hey, I Found A Good Book! (4, Funny)

tomblackwell (6196) | more than 10 years ago | (#8433621)

My friend wrote it! And I proofread it! And I'm submitting it to you! Strangely, I really liked it! Really!!

Pragmatic Extreme Programmer... (5, Funny)

kompiluj (677438) | more than 10 years ago | (#8432882)

Jeez, I like being both pragmatic and extreme when I use JUnit.

Is this book good for C++ programmers, too? (4, Interesting)

plover (150551) | more than 10 years ago | (#8432886)

I guess the question is, are the concepts in the book presented generically enough such that it would port (for a sufficiently loose definition of port) to another framework such as CppUnit?

Re:Is this book good for C++ programmers, too? (5, Informative)

mrob2002 (564229) | more than 10 years ago | (#8433028)

They certainly are. Most of the book is about how to write good unit tests, e.g. test the boundary conditions, and how to think clearly about what the boundary conditions are. I took enough away to start using nUnit successfully (nUnit is a framework for .Net unit testing). I've found unit testing extremely useful in day to day development, and this book taught me how. It's also available in PDF from the authors' web site if you prefer that format.

Re:Is this book good for C++ programmers, too? (2, Informative)

plover (150551) | more than 10 years ago | (#8433261)

Thank you, I'll have to add this book to my ever-expanding "In" queue of books. I've needed to "automate" my testing for some time now and while JUnit seems like the right way to go, it doesn't do much for a C++ project. But I've been reading up on CppUnit [sourceforge.net] and I think that's the way I'll go from here.

Thanks again.

Re:Is this book good for C++ programmers, too? (3, Informative)

(startx) (37027) | more than 10 years ago | (#8433514)

I'd also suggest looking at unit++ for your unit testing needs in any c++ project. Very easy to use, and just seems like the c++ way of doing things. Some of the "ports" of junit to c++ still seem to javaish for my liking.

Re:Is this book good for C++ programmers, too? (4, Interesting)

caseydk (203763) | more than 10 years ago | (#8434518)



Actually, I caught a presentation from Andy Hunt early last month and he talked about this directly.

They're releasing a version for C# shortly and they have the intent of releasing the book for a few other languages.

The most interesting part is that he told us that they're working to keep the language-specific content seperate from the main text. Therefore, they can write the applicable stuff in a given language and then LITERALLY run a makefile to make the next book.

Pretty sick (yet, pretty sharp), huh?

JUnit? (5, Funny)

Lando Griffin (698606) | more than 10 years ago | (#8432894)

Isn't that 50 Cent's group?

"JUnit, yeah, we'll take your ass out. JUnit, yeah, that's what we're about!"

G-Unit. (4, Funny)

bad enema (745446) | more than 10 years ago | (#8433000)

But I applaud your attempt.

Does it really matter? (n/t) (0)

Anonymous Coward | more than 10 years ago | (#8433176)


Of course not. (1)

bad enema (745446) | more than 10 years ago | (#8433324)

Does slashdot really matter? Does life really matter?

It's all perspective.

Re:JUnit? (0)

Anonymous Coward | more than 10 years ago | (#8433167)

Crew, man, it is crew...

Re:JUnit? (1)

the Man in Black (102634) | more than 10 years ago | (#8433180)

What's sad is, I clicked the topic specifically to write

"J-J-J-J-J-J-J J UNIT!"

Wonderfully, I wasn't the only one with that thought.

Re:JUnit? (1)

hookedup (630460) | more than 10 years ago | (#8433251)

Sadly, I was going to do the same too...

Re:JUnit? (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8434013)

No, Junit was a minor Egyptian goddess. So minor, in fact, that I can't find any specific information about her apart from this image [pege.org] (warning: contains nudity).

Personally, I'll never use this thing because I used to work with somebody who was sure that it didn't matter if his code ever worked, or if it was documented or if it did what it was supposed to do, as long as he wrote enough tests for it. Of course, anybody who didn't agree with him was automatically anti-testing and thus responsible for the project failing (nothing to do, of course, with the fact this guy had no idea what he was doing). Argh.

The company, you'll be glad to know, is out of business, so you'll never use that particular product, but the guy is alive and well corrupting code belonging to other companies.

Sorry, went on a tangent there, but 3 years later I still need to vent.

Wonderful book (1, Troll)

grub (11606) | more than 10 years ago | (#8432897)


Pragmatic JUnit Testing was the quantum leap I needed. Because of Pragmatic JUnit Testing, the lateral shift to JUnit was perfect. It wasn't a complete shock thanks to Pragmatic JUnit Testing. Overall I'd say it wasn't so much a complete paradigm shift but thanks to Pragmatic JUnit Testing, it helped me think outside the box.

Three cheers for Pragmatic JUnit Testing!!

Hip hip.. HOORAY!

Re:Wonderful book (1, Troll)

donnyspi (701349) | more than 10 years ago | (#8432926)

If I had mod points left, i'd give you -1 for using the phrase "paradigm shift". That is the most tired, overused phrase in the book.

Re:Wonderful book (0)

Anonymous Coward | more than 10 years ago | (#8432951)

The whole post was overused phrases, that was the point. :)

Re:Wonderful book (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432963)

Have you considered autoerotic asphyxiation?

Re:Wonderful book (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8432981)

I'd rather have a woman there but I'll take your word on how good it is by yourself.

Re:Wonderful book (0)

Anonymous Coward | more than 10 years ago | (#8433686)

Honey, you ain't had nuthin' 'till you've had a 325lb woman sit on your face. Your life truly flashes before your eyes as you pray she'll climax and roll off before you get brain damage.

Everything else is just pullin' your pud.

Re:Wonderful book (1)

PragDave (466044) | more than 10 years ago | (#8432959)

Except the word 'paradigm' doesn't occur in the book... :)

Re:Wonderful book (0, Offtopic)

Neil Blender (555885) | more than 10 years ago | (#8433020)

I am assuming you are from the Pragmatic Bookshelf based on your username. You might be interested to know that prag is slang for a prison bitch.

Re:Wonderful book (0)

Anonymous Coward | more than 10 years ago | (#8433575)

You might be interested to know that prag is slang for a prison bitch.

My condolenses for the flashbacks this has brought up.

Re:Wonderful book (0, Troll)

r.jimenezz (737542) | more than 10 years ago | (#8433039)

Searched the web for pragmatic junit testing. Results 1 - 10 of about 2,540. Search took 0.25 seconds 1. The Pragmatic Programmers, LLC Sorry dude, will have to repeat "Pragmatic JUnit Testing" more in your next post...

WORD (-1, Redundant)

Mach5 (3371) | more than 10 years ago | (#8432938)

Juh-juh-juh Juh-juh-juh JAY-UNNNITT /me flashes gang signs

my UID is lower than yours

Re:WORD (2, Funny)

Anonymous Coward | more than 10 years ago | (#8433280)

my UID is lower than yours

Apparently you beat me in the IQ department too.

The first book in this series.... (5, Informative)

tcopeland (32225) | more than 10 years ago | (#8432961)

...was a good one [pragmaticprogrammer.com] for learning about CVS.

Especially helpful was a small appendix which listed various recipes; i.e., the series of 3 or 4 steps necessary to merge a bugfix from one branch to another or whatever. I always forget the order of those cvs -j options...

from the better-than-sex dept. (1, Funny)

r.jimenezz (737542) | more than 10 years ago | (#8432979)

Sigh :( Such is the life of the geek...

Re:from the better-than-sex dept. (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8433030)

Four words: lap dances and whores

Nope. Sex is still better. (1)

bad enema (745446) | more than 10 years ago | (#8433081)

I guess I'm shallow like that.

extreme programming (1, Interesting)

tijnbraun (226978) | more than 10 years ago | (#8432989)

Is Junit any way linked with extreme programming [extremeprogramming.org] ? It sound that their goals are quite identical. However their ore information [extremeprogramming.org] more informationsection doesn't mention JUnit anywhere.

Re:extreme programming (4, Informative)

Abcd1234 (188840) | more than 10 years ago | (#8433087)

Err, JUnit and Extreme Programming are really pretty orthogonal. XP, which is a programming methodology, preaches the idea of writing unit tests before writing code. JUnit is a unit testing framework for Java. Therefore, JUnit can be useful tool in the practice of Extreme Programming, as it is designed for the express purpose of simplifying the creation of unit tests.

Re:extreme programming (4, Informative)

plover (150551) | more than 10 years ago | (#8433101)

Only in that extreme programming is a test-centric philosophy that requires you to continually recompile/test while developing.

My understanding of JUnit is that it's a test framework that simplifies running all the tests you've developed in conjunction with a project. So, if you use the JUnit foundation to build your unit tests, theory says that before turning your code over to the QA teams you'd run JUnit over the whole ball of wax to make sure you aren't sending out something stupidly broken.

But your question: "is JUnit linked with Extreme Programming" is a lot like asking if C++ is linked with Borland or Microsoft. If you're into extreme programming in Java and testing with JUnit, then yes, they're linked. And if you're into extreme programming in Java, then you're probably already using JUnit.

Re:extreme programming (1)

tijnbraun (226978) | more than 10 years ago | (#8433105)

Although I think that XP has some valuable ways of bugs to be found. My link should have been "more information" [extremeprogramming.org] .
The ore of bad programming can be probably found elsewere.

Re:extreme programming (0)

Anonymous Coward | more than 10 years ago | (#8433901)

Let's see, from juinit.org [junit.org] ....

JUnit is a regression testing framework written by Erich Gamma and Kent Beck...

From the credits for Extreme Programming Explained [amazon.com] ....

Kent Beck (Author), Foreward by Erich Gamma

Besides which, junit.org has links to 3 other extreme programming sites, so i'd say you're onto something...

Java (-1, Troll)

Tyler Eaves (344284) | more than 10 years ago | (#8433078)

So what does a JUnit call look like

JUnit unit = new JUnit.TestFramework.SimpleTest()
unit.setExpected Result(4)
unit.setPassMessage('Okay, exponention works...')
unit.setFailMessage('Uh oh...')
NumberFormatter format = new NumberFormatter()
format.setDecimalDigits(1)
for mat.setLocaleFractionalSeperator('.')
unit.setFor matter(format)
unit.runTest(Math.pow(2))

Seriously, kids, java is bad for you...

Re:Java (5, Informative)

tcopeland (32225) | more than 10 years ago | (#8433147)

I use a slew of JUnit tests for a project I work on (PMD [sf.net] ) - you can see all the code for the tests here [sourceforge.net] (thanks JXR!).

Here's an example of one of the PMD JUnit tests that checks the command line option processing:
public void testShortNames() {
CommandLineOptions opt = new CommandLineOptions(new String[] {"file", "format", "ruleset", "-shortnames"});
assertTrue(opt.shortNamesEnabled());
}
and another that makes sure that an Exception is thrown in another case:
public void testNullArgs() {
try {
new CommandLineOptions(null);
fail("Should have thrown an exception when null passed to constructor");
} catch (RuntimeException re) {
// cool
}
}
When I make a code change, I just rerun all the tests to make sure I didn't break anything. If someone reports a bug, I add a test so that bug won't reappear. Sweet.

Re:Java (5, Insightful)

Tumbarumba (74816) | more than 10 years ago | (#8433383)

So what does a JUnit call look like

JUnit unit = new JUnit.TestFramework.SimpleTest()
unit.setExpectedResult(4)
unit.setPassMessage('Okay, exponention works...')
unit.setFailMessage('Uh oh...')
NumberFormatter format = new NumberFormatter()
format.setDecimalDigits(1)
format.setLocaleFractionalSeperator('.')
unit.setFormatter(format)
unit.runTest(Math.pow(2))
Nah, more like this:

public void testPow() {
assertEquals( "Unexpected Math.Pow result", Math.pow(2), 4 );
}

Seriously, kids, java is bad for you...
Yeah, I can create a verbose, unreadable and unrealistic example in Perl, too. It doesn't make the language bad, rather it reflects badly on the programmer.

Re:Java (0)

Anonymous Coward | more than 10 years ago | (#8434903)

Yes... there are plenty of other things making Perl a bad language.

Unit tests are a bad idea (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8433108)

I'm posting anonymously for obvious reasons.

I'm a teaching assistant (TA) at Harvard University, and I mark a lot of Java code as part of a job that supports my PhD studies. Code submitted to me with unit tests face an automatic 5 mark penalty, before i even begin marking. There are several reasons for this.

  1. Extra code == extra bloat. The unit test code is submitted as an extra class file, which means there is one more thing that I have to read over before I can judge their code on its merits. I find that unit tests are a pain to compile, normally found deep in a directory structure where they make little sense.
  2. Too much documentation. People who submit unit tests generally document the interfaces using javadoc, which just increases the amount of reading I have to do before I can assign a mark. HTML as a documentation format is stupid. There is nothing wrong with submitting code with comments at the start of a function or method and leaving it with that. If the code needs documentation because it is doing something non-obvious, it is time to rethink the code.
  3. Unit tests are written with no extra skill than the code they test. Unit tests induce a level of confidence in the programmer that their code works as a black box. This is a bad idea. Programmers should understand why each and everyone of their modules works the way it does, not assume that everything is well because it passes some rudimentary test that was created with the same skill level as the rest of their code.
As you can see, I'm against unit testing. I've tried my hardest to get the profs to teach i386 assembly and then C so that students understand how a computer works, but to no avail. If we are to regain our jobs from the Indians, we must be more professional coders.

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433182)

So you're against extra documentation and over-verboseness?

Re:Unit tests are a bad idea (0, Troll)

Pfhreakaz0id (82141) | more than 10 years ago | (#8433193)

My thoughts exactly. Before that was my first thought "who the hell, exactly, has time for this in a real job?"

Re:Unit tests are a bad idea (2, Informative)

Anonymous Coward | more than 10 years ago | (#8433211)

Junit tests are meant to be fairly simple and if used correctly (e.g. run after every change) can really help to reduce bugs and thus save you time.

where the whole unit testing idea falls down is when you have things you can't unit test like jsps and servlets, these require much more complex testing methods.

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433894)

Actually you can unit test things like jsp and servelets (read the book!) by using mock objects or in-container tests. Really simplifies the process.

Re:Unit tests are a bad idea (1)

plumby (179557) | more than 10 years ago | (#8433940)

The correct question is "who the hell can afford not to do this in a real job?"

Our IT department (one of the largest credit card companies in the UK - so a "real job") adopted unit testing as part of the development process on everything from Java to Cobol about 2 years ago. Quality has increased significantly, and I don't think any of the developers would feel comfortable coding without it now.

Re:Unit tests are a bad idea (4, Interesting)

tcopeland (32225) | more than 10 years ago | (#8433201)

I'm not sure if this is a troll or not... but, what the heck.

> Extra code == extra bloat

Writing tests helps student understand their code and track down bugs. If you don't want students to submit tests, tell them not to.

> Too much documentation

What does JavaDoc - which the compiler discards - have to do with unit tests?

> Unit tests are written with no extra
> skill than the code they test

Don't throw the baby out with the bathwater. If a student is writing tests, at least he's trying to improve his code quality. You're a grad student; show him how to write better code _and_ better tests.

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433209)

You sir are an idiot. You obviously have never left the confines of your little academic cave and been out in the real world. How the hell you got into Harvard is a mystery to me and just validates my increasing suspicions that Ivy League schools are no better than the local community college.

Re:Unit tests are a bad idea (1)

Q Who (588741) | more than 10 years ago | (#8433243)

Harvard CS department is not considered strong.

Re:Unit tests are a bad idea (1)

RedMage (136286) | more than 10 years ago | (#8433434)

Hey hey hey!! Watch where you're throwing that troll, dude! CS at Harvard is quite strong, our AC posting notwithstanding... We're not all jerks, ya know...

RM

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433854)

What are you studying?

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433307)

What do you expect from Harvard "No one ever gets a B" University?

Re:Unit tests are a bad idea (5, Informative)

Xenographic (557057) | more than 10 years ago | (#8433212)

Odd, when I took an obligatory basic Java course, the grading was quite the opposite. They WANTED javadoc, they WANTED good comments, and they WANTED us to make sure the code worked right.

They went so far as to give us a few test cases (and if we didn't pass those test cases, we got a zero).

In fact, most of the grading process was to have their automatic system compare the output of our solution with the reference solution...

That said, the TAs were known to be lazy and I don't think anyone ever actually read our comments. I found this out when my solution differed slightly from what they expected (you had to do something different than they expected to direct the output to a file, namely java SomeProg > output, which was WELL commented...) and they couldn't figure it out... (hell, they didn't understand what that DID when I talked with them...)

So I can believe that you're a TA, but beyond that...

Re:Unit tests are a bad idea (1)

D-Cypell (446534) | more than 10 years ago | (#8433729)

This pretty much highlights where I find my faults in the system. Is it commented? Check! Is it Javadoced? Check! Does the output matched the expected output Check!

Doesnt matter if the code is poorly designed, inefficient and doesnt use the most appropriate library classes.... it passed the checklist...A+

Of course those that know me, know I have a fairly strong bias against formal education...

but i can neither confirm not deny that! ;o)

Re:Unit tests are a bad idea (2, Interesting)

Anonymous Coward | more than 10 years ago | (#8433213)

You are a fool. Yes, it does add to the bloat of code that you have to read through (poor baby!) but considering the unit test isn't ever shipped as the final product it adds nothing to the finished product besides proof that the program might work.

I cannot ever begin to express how amusing it is to hear a guy say that he wants professional coders and then complain that unit testing gives him more documentation to read. The horror!

That reminds me, I need to call up M$ and tell them that I want a patched version of XP that doesn't include any help documents. Real coders don't need documents.

If you have this TA, change your class now.

Re:Unit tests are a bad idea (5, Insightful)

HarpMan (53271) | more than 10 years ago | (#8433239)

Um, this is a joke, right? You teach at Harvard!!??? Now I know why we're losing all our jobs to offshoring. If this the best 'teaching' our educational system produce, we're really in trouble.

Seriously, it sound like your objections are just based on laziness - you don't want to look at extra code, documentation, etc. Too much work for you. Oh, that's another reason we're losing to offshore folks - laziness.

I guess we're illogical too. What does documentation have to do with unit testing? Can't you do one without the other???

Sorry, I'm just flabbergasted.

MOD PARENT UP (0)

Anonymous Coward | more than 10 years ago | (#8433296)

See subject.

Re:Unit tests are a bad idea (2, Insightful)

Anonymous Coward | more than 10 years ago | (#8433274)

I've tried my hardest to get the profs to teach i386 assembly and then C so that students understand how a computer works, but to no avail.

Teaching i386 then assembly would be a sure-fire way to mentally scar and/or fail 99% of your students. You simply can't presume that all students have the level of competency in computing that learning i386 requires when they first start a computing degree.

This competency can be picked up, and I'm not arguing that both assembly (to a certain degree) and a lower-level language like C are necessities for any good computing graduate, however a nicer ride at the beginning of the road is also a necessity. Giving someone an i386 reference manual and telling them to code won't produce more professional coders, it will instead drive away bright students who perhaps just don't have the necessary computing skills yet.

Re:Unit tests are a bad idea (5, Insightful)

outcast36 (696132) | more than 10 years ago | (#8433289)

Your arguments are pretty valid for a TA who is trying to grade Java II homework assignemnts. But for people writing business systems there are some benefits.

  1. Extra code == extra bloat- In the business world we call this CYA. You write the tests, they run green. If something breaks, you didn't write crappy code.
  2. Too much documentation- Does anybody have this problem? I wish every system I touched had too much documentation
  3. Unit tests are written with no extra skill than the code they test- You bring up an intersting point here, and you are correct. For systems doing something novel or complicated, having the dev write the test makes no sense. However, most of the apps out here connect back to a CRM db, or fire off an email when something is done.... super boring stuff. A competent developer already has an understanding of these things and is more than capable of writing a test.


anywho, your students are going to end up as PHBs & the rest of us would appreciate it if you didn't turn them off to testing before unleashing them onto the working world. Thanks.

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433587)

In the business world we call this CYA. You write the tests, they run green. If something breaks, you didn't write crappy code.

No. That means you have crappy code AND crappy testing. Unit testing is perhaps the least amount of testing you should do. It's so minimal, I think of it as nearly useless. Not entirely useless, but nearly. If you're not doing more comprehensive tests that take into account how components work together, then you are not testing at all. You can put together a dozen modules that all pass unit tests and have the full program fail disaterously. Unit testing proves nothing more than the module can pass the unit tests. It says nothing about the final quality of the code.

Re:Unit tests are a bad idea (5, Insightful)

TeaEarlGreyHot (756865) | more than 10 years ago | (#8433290)

Every day I am reminded why the universities consistently fail to produce programmers who can work in the real world (assuming this wasn't just a troll).

In the real world, code isn't handed in, marked, and that's that. Code is checked in, becomes part of a large, complicated system, and sometimes goes unvisited until years later, when entirely different personel have to take a gander at it and figure out what the heck it does, and why it was designed the way it was.

The more comments and documentation, the better.

In my current job, I'm in the middle of trying to untangle a badly-designed subsystem so it can be redesigned for new applications. There's no documentation, no unit tests. Only very high level descriptions of the I/O. The business logic is buried deep in the code, costing the company weeks of my time sifting through code. Some documentation on the outside would have cost a little bit more then, but saved a whole lot now.

Furthermore, if your interfaces between subsystems are well-designed, JUnit should be all you need to warrant that YOUR code will interact with the rest of the project according to the specification. And if there's a problem, it's the specification's fault, not yours. Granted, JUnit isn't really used class-by-class, but it is very useful a step above that, when it comes to integrating your code into a large project.

The problem in the academic world is there is no concept for how hugely huge projects get in the real world. No one is taught proper methodologies and good software engineering. Every assignment is a microcosm, and the short, quick, bang-out-the-code-and-ask-questions-later technique is what gets promoted in the process.

I'm sure there are schools that aren't like this, and I'm making sweeping generalizations, but this is what I have seen.

Re:Unit tests are a bad idea (1)

dduck (10970) | more than 10 years ago | (#8434093)

Hmmm... The course I teach [www.itu.dk] at the IT University of Copenhagen [www.itu.dk] is not like that. In fact my area of responsibility is development tactics and strategies, including assertions, exceptions, logging, JUnit, Ant, Design by Contract, CVS etc.

We learn from our mistakes and the world moves on... When I enrolled at comp sci at the U of Copenhagen there was no email, no web, no Java, no XP, no UNIX and no CSCW and HCI courses. That was a bad idea, so we learned.

Re:Unit tests are a bad idea (3, Insightful)

Anonymous Coward | more than 10 years ago | (#8433300)

You know that instead of having to read all of this code you could just write a unit test yourself and determine pass/fail according to that. Then you wouldn't have to actually read (poor thing) the stuff that is given to him to read...

Of course that would require the thought process of a real programmer. Seems the Ivy Leagues aren't all they were cracked up to be. I won't be hiring any Harvard graduates for quite some time...

Re:Unit tests are a bad idea (1)

perkr (626584) | more than 10 years ago | (#8433499)

You won't be hiring someone from Harvard U because of an anonymous shittalker on slashdot?? ;-)

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433564)

What?

Don't you make important decisions based on troll comments too?

Re:Unit tests are a bad idea (0)

Anonymous Coward | more than 10 years ago | (#8433345)

If the code needs documentation because it is doing something non-obvious, it is time to rethink the code

This has always been my opinion about code with way too many comments. People seem to think comments fix the code, when they really are only explaining something illogical in detail. As for unit testing, people who promote unit testing alway add the clause "If used correctly...". Correctly How? In my opinion unit testing is an idea only suitable for very specific applications. To use it as a general rule is worthless.

Re:Unit tests are a bad idea (5, Insightful)

RedMage (136286) | more than 10 years ago | (#8433353)

Well, I teach at Harvard also... And I'm glad I haven't run into you! Seriously, such arrogance has no place in a teaching situation.

1. Extra bloat my eye! What you're saying here is that you're a lazy bum and can't read through extra class files. If you want to do something constructive then how about instructing on how to lay out a project intelligantly?

2. Too much documentation? Again you're just a lazy TA and have no place grading. Regardless of the merits of HTML as a documentation medium, documentation is usually much more useful in grading than the actual code: it shows the thought process behind the code. Sure, I'm interested in that the code works as advertised, but I'm also interested in how you got there. It makes my job much easier to keep my students from falling into common pitfalls.

3. I do agree here, but not as far as the basic premise that unit testing is bad. Bad tests are useless, while a good test can be rather helpful, especially in a regression situation. Teach your students how to write good test and their code will be better. Punish them for writing bad tests and they'll never test.

Obviously you're not too proud of your convictions, or you wouldn't be an AC. I feel sorry for any professors you work with. I know mine are happy to work with me...

RM

Re:Unit tests are a bad idea (1)

Lewisham (239493) | more than 10 years ago | (#8434352)

Thank god for that. I was about to fire off a simple "Not here, buddy" comment, but I'm glad that someone who is actually a TA sorted it out.

I'm studying at the University of Bristol right now, and we've been taught pretty well so far, I think. We started off with C (that guy wants assembler? Seriously?!) and then worked to Java, which helps a lot. Getting thrown in at the segmentation fault deep-end has it's advantages :)

As soon as we moved to Java, it's been taught as part of the Software Engineering units, so it's put into the context of The Real World, rather than just: "This is the Java syntax, now write me some programs." We're all aware that the marking itself is done by unit testing (it's even stated on the submission page where we upload the work), and our lecturer has made us write programs where we used JUnit testing on it. If the program was great, you still only got 50%. The testing also had to prove something in order to start getting the next 50%. We were also encouraged from the outset to Javadoc as much as possible.

So yeah, we've always been taught comments + testing == good, lazy == bad. I really couldn't believe that that was a rarity.

Chris

Re:Unit tests are a bad idea (5, Insightful)

Anonymous Coward | more than 10 years ago | (#8433396)

I'm posting anonymously for obvious reasons.

You're totally clueless, and don't want anyone to know? ;-)

I'm a teaching assistant (TA) at Harvard University, and I mark a lot of Java code as part of a job that supports my PhD studies. Code submitted to me with unit tests face an automatic 5 mark penalty, before i even begin marking. There are several reasons for this.

You are a total moron...of course not many go to Hahvahd for CS studies. I wonder what your counterparts at real engineering schools like MIT or CalTech have to say about your viewpoint... Actually my best guess (and hope) is that you're a troll trying to land fish such as myself... ;-)

Extra code == extra bloat. The unit test code is submitted as an extra class file, which means there is one more thing that I have to read over before I can judge their code on its merits.

Oh, so the good programming practices of your students make your life more difficult - so you penalize them? You should be fired.

I find that unit tests are a pain to compile, normally found deep in a directory structure where they make little sense.

Of course the unit tests must be at the proper place in the directory heirarchy, or they wouldn't compile (Java namespace implementation). So, I doubt you know what you're talking about.

Too much documentation. People who submit unit tests generally document the interfaces using javadoc, which just increases the amount of reading I have to do before I can assign a mark. HTML as a documentation format is stupid. There is nothing wrong with submitting code with comments at the start of a function or method and leaving it with that. If the code needs documentation because it is doing something non-obvious, it is time to rethink the code.

Er, Javadocs aren't written in HTML...HTML is generated from Javadocs. As to your other remarks regarding code documentation, obviously you've never done any real-world programming. That is often a problem with PhD. candidates.

Unit tests are written with no extra skill than the code they test. Unit tests induce a level of confidence in the programmer that their code works as a black box. This is a bad idea. Programmers should understand why each and everyone of their modules works the way it does, not assume that everything is well because it passes some rudimentary test that was created with the same skill level as the rest of their code.

Code should work like a black box. That is the exact idea of encapsulation, a primary tenet of OO programming. You are quite obviously a troll with nothing to contribute to this discussion.

As you can see, I'm against unit testing. I've tried my hardest to get the profs to teach i386 assembly and then C so that students understand how a computer works, but to no avail. If we are to regain our jobs from the Indians, we must be more professional coders.

Ah yes, the final prong on the hook. How many of those Indian coders do you think do "i386 assembly" and "C"? Just around 0%...and don't fool yourself into thinking that either of those disciplines will do much to make entry-level coders better programmers. The important concepts are algorithmic, numeric and complexity oriented. Programming language isn't so important...and the more expressive and less bug-prone the better. Java is a pretty good choice, and has the added benefit of being widely used in the "real world" - a place you're obviously not too familiar with yourself.

Re:Unit tests are a bad idea (2, Interesting)

Oligonicella (659917) | more than 10 years ago | (#8433420)

Academia. Land of TA's who want to do as little work as possible to earn that money that supports their studies.
Your 1,2,3 are all faulty if applied to the working world. Which, by the way, is where real life is.
Your last sentence has a blob of irony in it. Can you spot it?

Re:Unit tests are a bad idea (1)

zx75 (304335) | more than 10 years ago | (#8433457)

I know this'll be flamebait, but it is TAs like you that we (as a student myself) absolutely hate. You remove marks that we are working hard to earn for creating robust code that we go out of our way to prove that it works correctly, even in circumstances outside of the specification. 'It is less efficient' yeah right, am I taking a course on code optimization here? When we write code that is fast, efficient, but can fail on outside of scope or illogical input, we get reamed out because it failed. When we make code robust and only accept valid input, it gets thrown in our face as inefficient.

Too often these days there is not enough testing done, resulting in buggy programs that are flaky at best, production code or not. You should be encouraging your students to do these things so that they can learn it the right way the first time.

It may not matter to you that you'll write off 5 marks for handing in a complete program because it is 'bulky', but it matters a hell of a lot to the student that you just did that to.

Re:Unit tests are a bad idea (1)

wfberg (24378) | more than 10 years ago | (#8433501)

I'm posting anonymously for obvious reasons.

I'm a teaching assistant (TA) at Harvard University, and I mark a lot of Java code as part of a job that supports my PhD studies. Code submitted to me with unit tests face an automatic 5 mark penalty, before i even begin marking.


And.. you don't want the students to know this? Or you don't want the professor to know this? Isn't the marking supposed to be at least somewhat transparant? Why else post anonymously?

Your points;

1) extra code is extra bloat; I'm sure it's entirely up to you to disregard any testing code delivered that was not required. Although, shouldn't you be testing their code to begin with (rather than *only* reviewing it - full marks for style, but it doesn't compile)?

2) too much documentation; well, yes, if every line is commented, that's too much documentation; javadoc on the other hand documents methods, not lines of codes; in fact, used correctly, it documents interfaces, not the implementation. Things like pre- and postconditions, race conditions, that sort of thing. Javadoc is great.

And javadoc is not just HTML; and it's right there "at the start of a function or method". (Java only comes with methods btw, mr.Harvard).

3) Unit tests are written with no extra skill than the code they test; this is usually true of any test; such is the nature of tests. Happily, it usually takes less effort to come up with tests than it does to come up with "perfect" code, which is why they're useful. For example; a parser should parse certain arbitrary documents in the specified grammar, and correctly at that, and not dump core. Coming up with the test-cases is easier than writing a parser.

Your argument might just as well be applied to a whole slew of other IT methodologies that students have to learn, like for instance coming up with Use Cases or UML Class Diagrams; in the real world these are useful tools for communication with others, in school you end up implementing the stuff you designed yourself; so what?

Re:Unit tests are a bad idea (3, Insightful)

Delirium Tremens (214596) | more than 10 years ago | (#8433521)

Come on, people, relax. The above comment (#8433108 [slashdot.org] ) is obviously a Troll.
It is very well crafted, but it does show all the characteritics of a Troll. Honest tone, but inflamatory arguments. Personal testimony (supposedly), but anonymous post. 'Insightful' opinions, but lack of touch with the actual matter etc ...

Re:Unit tests are a bad idea (1)

ZX-3 (745525) | more than 10 years ago | (#8433755)

I've tried my hardest to get the profs to teach i386 assembly and then C so that students understand how a computer works, but to no avail.

If you got a CSE degree at a lesser Ivy (Penn) in the early-to-mid 90s, you would have learned SPARC assembly in the 200-level compilers course and 68000 assembly in the 300-level digital design courses.

Re:Unit tests are a bad idea (4, Funny)

Anonymous Coward | more than 10 years ago | (#8433756)

I'm posting anonymously for obvious reasons.

I'm a teaching assistant (TA) at Beaver College, and I mark a lot of Java code as part of a job that supports my PhD studies. Code submitted to me that works faces an automatic 5 mark penalty, before i even begin marking. There are several reasons for this.

1. Working code == extra effort. Code submitted that actually runs means that I have to read over before I can give the code an arbitrary, uninformed grade. I find that working code makes me have to figure out how to compile it, which is terrible since I have no clue what I'm doing.
3. (I can't count.) Working code is written by people who are more skilled than I am. Working code induces a level of confidence in the programmer and they think they are better than me. This is a bad idea. Programmers should understand why each and everyone of their modules shouldn't work, and not assume that everything is well because it actually does what it was documented to do.

As you can see, I'm against working code. I've tried my hardest to get the profs to teach abacuses and then flip lots of little switches so that students understand how hard it is to make a computer work, but to no avail. If we are to regain our jobs from the Indians, we must be more arrogant a-hole coders.

Re:Unit tests are a bad idea (1)

ameoba (173803) | more than 10 years ago | (#8434881)

You, like most grad students in CS departments (I'm one myself) are an arrogant, self-centered prick. You might as well be docking 5 points every time you see somebody use indentation that you don't approve of or tabs instead of spaces (or vice versa).

You see, as the TA for the class, it's not your place to decide these things, it's the professor's. I'm sure that every time you do something arbitrary like this, the student is going to turn around and complain to the prof, who is more than likely to give them their 5 points back.

Dave Thomas (-1, Offtopic)

stratjakt (596332) | more than 10 years ago | (#8433162)

Is that Dave Thomas, founder of Wendy's or Dave Thomas aka Doug McKenzie?

I met Andy Hunt's brother Mike at a social event once, a brilliant man indeed.

Next week's book review (3, Funny)

Anonymous Coward | more than 10 years ago | (#8433221)

Next week, Steve Ballmer reviews "The Road Ahead"

I've read the book..... (0, Offtopic)

dannyelfman (717583) | more than 10 years ago | (#8433298)

And no where in there does it talk any thing about Hamburgers [wendys.com] or about adoption [wendys.com] .

Infact, the only thing I come to expect from Dave Thomas is that he's pushing up daises.....

Wrong Dave Thomas (0)

Anonymous Coward | more than 10 years ago | (#8433335)

It is the Dave Thomas from the old SCTV series.

So take off, hoser ;)

What if it's your job? (0)

Anonymous Coward | more than 10 years ago | (#8433413)

But what about those of us who hate testing, and it's our job?

Question on the book (3, Interesting)

pcraven (191172) | more than 10 years ago | (#8433958)

I've found it very difficult to write good tests on applications that were web-based, and highly dependent on the data. Does this book have good solutions for these problems?

Re:Question on the book (5, Informative)

congaflum (754687) | more than 10 years ago | (#8434378)

It does offer some solutions and advice to those, although I'd have liked to see more of the book devoted to it. I think most folk can easily see the benefits of unit testing when shown simple examples (like writing tests for a linked list or a temperature converter or something), but it takes a fair bit more effort to learn how to apply tests to "real world" code.

From what I've learned so far, there are 2 main things that'll help you write unit tests for these sorts of situations: one is to mercilessly refactor your code as you go, and soon you'll probably find it naturally becomes easier to test. Seperate any database code from the application logic, for example, and you'll probably find that the application logic becomes pretty easy to test.

The second thing is mock objects. The typical example of these is (again) database code. By making a little mock implementation that only *looks* like it's really writing to a database you can often then test other parts of your code without having the hassle of setting up sample data, cleaning it back out afterwards and so on. In web apps, you may find it handy to have a mock implementation that pulls page requests, effectively pretending to be the browser.

One other thing, which sounds a bit smug but is actually very true: if you start out writing tests from the beginning of a project, it will probably remain easy to test. On the other hand, if you take an existing codebase and try to retrofit tests onto it, it's more than likely that you'll have to rearrange a lot of code in the process... Cheers.

Why Unit testing is a GOOD idea (5, Insightful)

Anonymous Coward | more than 10 years ago | (#8434435)

Responding to the post above, there are a number of 'hidden benifits' to writing Unit tests for Real Programmers (and not Teacher's Assistants).

1) It's fun (sad but true). I write my test cases first, and that gives me a chance to challenge myself. I'll try and write tests that are very comprehensive or hard to pass (but only if they adhere to the specification). I then hide the tests while I implement the code to see how much I remembered.

2) It helps me seperate the notion of System code from Client code. This is pretty important because I'm often both the system architect and the client coder, and it's often hard to keep the two distinct when you're doing both.

By writing the tests first, you are forced to think of the (unwritten) code as a client of the system. You ask yourself, 'How should this module work? What are the most simple and logical interfaces?' You then write code to those interfaces, and end up with clean architecture. You then implement the code to pass the tests.

While that doesn't sound revolutionary, I find that without tests I have a tendency to let the logic dictate the interface. For example, I find myself thinking, 'this method would be really efficient if rather than receiving an abstract widget, it took 4 int args' (or something like that).

There are some other benefits to Unit testing (code stability, confidence, etc), but those two were surprising 'discoveries' when I started unit testing.

Unit testing is great... (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#8434716)

For projects that never ship. If your working in some massive back office, on some huge accounting app due buy late 2008, unit testing is a great way to occupy your time. Go ahead get them code coverage numbers up to 100%. Spend hours and hours writing tests for problems that will probably never occur. Brag about how perfect your code is at the water cooler, because you have so many unit tests, it's proved to be prefect. Ride that green bar for all its worth comrade!

Dismiss management concerns over how long the project is taking; after all perfect code takes time! You can prove to management that the code is great by all of the wonderful unit tests you've written.

But pray you don't ever ship the code, it must never go into production. Because if it does you have to explain why your perfect code has bugs, just as many as code without unit tests. And why your application is significantly slower then non unit tested apps.

Unit testing just wastes time.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>