Unit Testing - What exactly is it?

Can anyone recommend a good "total beginners" guide to what unit testing is, how it works, what it's good for and under what circumstances you'd use?  Everything i've found seems to assume a level of knowledge about it that i just don't have yet.

Aussie Poster #7
Monday, May 10, 2004

For a really simple intro, a good book is:

http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/qid=1084231527/sr=1-1/ref=sr_1_1/103-3451262-2004621?v=glance&s=books

This will give you a good insight into what the current term "Unit testing" really means. It doesn't, unfortunately, give you a good idea of how to do unit testing on "real world" problems, unfortunately. But it's a start.

Chris Tavares
Monday, May 10, 2004

It is Black Box testing in the language of software engineering. You code one module and do business validation on the coded module.

When you group these individual modules and perform major testing which is called to be White box testing in software engineering and which is same as integration testing.

Hemang Joshi
Monday, May 10, 2004

I'd like to do some Unit Testing but my Match.com ad isn't generating any leads.

Jorel on Software
Monday, May 10, 2004

The Beck book is a very good recommendation.
Pragmatic Unit Testing by Hunt and Thomas is another good one.
(Hunt and Thomas have two editions last time I looked.  One using Java and one using C#)

bob
Monday, May 10, 2004

The JUnit website has links to a ton of testing articles:

http://www.junit.org/news/article/index.htm

Chris Winters
Monday, May 10, 2004

Also, there are differences between the terms "Unit Testing" and "Test Driven Development".

The former means writing automated tests that can be run automatically to ensure that things aren't broken. It usually means using a framework, like the xUnit frameworks (JUnit, NUnit, CPPUnit, etc.).

The latter expands on the former to say that proper unit testing is really all about writing the tests first. A couple reasons this is considered good practice is: 1. The tests never have any knowledge of the implementation, since the implementation doesn't exist yet; 2. The tests scope the implementation work, since you write code until the tests succeed, then stop. If you need more functionality, you write more tests -- first.

Brad Wilson (dotnetguy.techieswithcats.com)
Monday, May 10, 2004

I'll second the recommendation for "Pragmatic Unit Testing". At one point, they had a PDF version which could be purchased.

Mark Hoffman
Monday, May 10, 2004

To briefly correct something someone else said:

Unit tests are not "black box" testing. Typically, they are more or less white box testing.

Black box testing means testing without using knowledge of the internal design and/or code.

White box testing means the opposite: testing based on how the internal code / design works. Unit tests typically exercise small pieces of the code - you may write a new function, then write some unit tests for that function.  For example, you might write some code that passes invalid parameters to the function and verifies it handles the error condition gracefully, doesn't crash, etc.

Unit testing is almost always white box, not black box.

Mike Treit
Monday, May 10, 2004

I disagree completely.

When I write unit tests, it's black-box testing.  I write the test *before* I write the code being tested.  In general, I have no foreknowledge about how I will implement that code while I'm writing the tests.

bob
Monday, May 10, 2004

Unit testing is really just about testing individual units of code in isolation from the system that they are integrated into. The term unit refers to a small section of code, typically a function or a small group of functions.

You can unit test in any number of ways, but many developers think it's helpful to write some code to exercise the unit. They can then run and re-run the test code (regression test) whenever they make a change to the unit, and verify that they didn't break something that previously worked (as long as they tested for it in the first place.) This is what's known as automated unit tests.

Big B
Monday, May 10, 2004

FYI, seems like "Pragmatic Unit Testing" is not available on Amazon. You'll find those two books here:

http://www.pragmaticprogrammer.com/

Fred
Tuesday, May 11, 2004

For an elementary introduction you could try chapters 13, 14 & 16 of 'Dive into Python' at http://diveintopython.org. You don't need more than a smattering of python to understand the process and the pyUnit module that provides the framework.

David Roper
Tuesday, May 11, 2004

I think this is more or less what you're looking for (PDF) :

http://www.pragmaticprogrammer.com/starter_kit/utj/whatis.pdf

Pakter
Tuesday, May 11, 2004

Bob,

I think your unit tests are white-box even if you don't "know" how you will implement your code before you write the test.

Once you finish the design you probably have a better idea of how to test it. In that case you go back to the tests and add/rewrite to get better test coverage.

Also, I imagine there are some portions of your code that don't get tested because you are confident it will just work (examples are vanilla get/set methods, simple constructors, methods on subclasses that weren't overridden,  etc...). So you are adjusting your unit tests based on the expectation that certain things you write don't need testing because they contain little implementation detail.

NathanJ
Tuesday, May 11, 2004

Oreilly will be printing the Pragmatic series of books

http://press.oreilly.com/pub/pr/1171

new_one
Wednesday, May 12, 2004

  Recent Topics

  Fog Creek Home