Is a 2003 book still useful for learning JUnit ?

[Ali Gordon]

I came across what seems to be a nice beginner book to learn JUnit - Pragmatic Unit Testing in Java with JUnit.
Can someone please tell me if this 2003 book would still be relevant today ? If not, is there a similar beginner
book of < 250 pages for learning JUnit ?

Thank you.

[Jeanne Boyarsky]

While I love that book, I think you are better off using a book that teaches JUnit 4. "Test Driven" is excellent. It is more than 250 pages. But you dan skip the later chapters as they cover more advanced concepts. And go back to them when you need to test code like that.

[Ali Gordon]

Jeanne Boyarsky wrote:While I love that book, I think you are better off using a book that teaches JUnit 4. "Test Driven" is excellent. It is more than 250 pages. But you dan skip the later chapters as they cover more advanced concepts. And go back to them when you need to test code like that.

Thanks. I saw test-driven. It has little practical knowledge. I need something more hands on, with the theoretical stuff. I felt like I was in a philosophy
class instead of a developer class when I read that book.

[Thakur Sachin Singh]

you can read the below books and both are very good books

1. JUnit Recipes - Practical Methods for Programmer Testing
2. Junit in action

[Ali Gordon]

Thakur Sachin Singh wrote:you can read the below books and both are very good books

1. JUnit Recipes - Practical Methods for Programmer Testing
2. Junit in action

Have you read those books ? First one us very old and is a recipe book. Second one has poor reviews, but I will check it out.
I hate the "ZZZ in action" series books. Never good for beginners.

[Jeanne Boyarsky]

Ali Gordon wrote:Thanks. I saw test-driven. It has little practical knowledge. I need something more hands on, with the theoretical stuff. I felt like I was in a philosophy
class instead of a developer class when I read that book.

Can you elaborate on what you found theoretical in "Test Driven"? I found it to be one of the more practical books that I've read. He covers a lot of the scenarios that show up in the real world. Recipe books are the other end of the continuum, but that doesn't sound what you are looking for.

Another way of thinking about this - what are some books you liked the style of? Not about JUnit, just in general. Knowing that will help us recommend something you might like better for JUnit.

[Bear Bibeault]

Ali Gordon wrote:I hate the "ZZZ in action" series books. Never good for beginners.

It depends upon the book. You need to carefully pay attention to the intended audience for the book. The preface to my jQuery in Action (2nd Ed) book clearly states that the book is not for someone who is completely unfamiliar with JavaScript, though no prior jQuery experience is necessary.

[Ali Gordon]

Jeanne Boyarsky wrote:

Ali Gordon wrote:Thanks. I saw test-driven. It has little practical knowledge. I need something more hands on, with the theoretical stuff. I felt like I was in a philosophy
class instead of a developer class when I read that book.

Can you elaborate on what you found theoretical in "Test Driven"? I found it to be one of the more practical books that I've read. He covers a lot of the scenarios that show up in the real world. Recipe books are the other end of the continuum, but that doesn't sound what you are looking for.

Another way of thinking about this - what are some books you liked the style of? Not about JUnit, just in general. Knowing that will help us recommend something you might like better for JUnit.

Firstly, I think there is too much blah blah going on. I feel like I am listening in on coder gossip. Sampler -

Quality comes in many flavors

Evidenced by the quality assurance departments of the corporate world of today, 
people tend to associate the word quality with the number of defects found after 
using the software. Some consider quality to be other things such as the degree to 
which the software fulfills its users’ needs and expectations. Some consider not
just the externally visible quality but also the internal qualities of the software in
question (which translate to external qualities like the cost of development, main-
tenance, and so forth).  TDD contributes to improved quality in all of these aspects
with its design-guiding and quality-oriented nature.
Quite possibly the number one reason for a defect to slip through to produc-
tion is that there was no test verifying that that particular execution path through
our code indeed works as it should. (Another candidate for that unwanted title is
our laziness: not running all of the tests or running them a bit sloppily, thereby
letting a bug crawl through.)
TDD remedies this situation by making sure that there’s practically no code in
the system that is not required—and therefore executed—by the tests. Through
extensive test coverage and having all of those tests automated,  TDD effectively
guarantees that whatever you have written a test for works, and the quality (in
terms of defects) becomes more of a function of how well we succeed in coming
up with the right test cases.
One significant part of that task is a matter of testing skills—our ability to
derive test cases for the normal cases, the corner cases, the foreseeable user
errors, and so forth. The way  TDD can help in this regard is by letting us focus on
the public interfaces for our modules, classes, and what have you. By not knowing
what the implementation looks like, we are better positioned to think out of the
box and focus on how the code should behave and how the developer of the cli-
ent code would—or could—use it, either on purpose or by mistake.
TDD ’s attention to quality of both code and design also has a significant effect
on how much of our precious development time is spent fixing defects rather than,
say, implementing new functionality or improving the existing code base’s design.

Why do I need so much fluff ? He can say it like this -

According to different people quality of code can mean - number of defects discovered after using the software, internal or non visible traits like cost of dev, maintenance etc.
Through extensive test coverage (the percentage of your code for which you did tests) and having all the tests automated, TDD effectively guarantees that whatever you have
written a test for works, and the quality (in terms of defects) becomes more of a function of how well we succeed in coming up with the right test cases.
With TDD (test-code-refactor), you save time by writing software in increments that WORK instead of making huge code, testing it in the end and discovering many bugs.


Eg. For theoretical (I found one now) -

Figure 1.6 With incremental development—building the whole system in small increments—we are never
far from an integrated, working code base. This reduces risk, because the inventory of unfinished work
remains small. As we’ll learn later on, incremental development also enables effective learning through
early feedback based on the customer and developers constantly seeing actual, working software

Mark dexter's tuts, although meant to mainly teach eclipse, taught me way more practical TDD with Junit than this book.