JUnit in Action
ASIN: 1930110995
Average Customer Review: 4.5, based on 17 reviews.
Customer reviews (5 of 17)
Good book, but needs new version., 2007-03-10, Rating: 4.
With the new Junit4, the book needs a new version.
Good Introduction to UNIT testing, 2007-02-28, Rating: 4.
I read this book pretty much from cover to cover. I found it to be a nice introduction to the unit testing strategy now widely employed in software development projects. This book does put the testing procedures in perspective and it touches upon different types/levels of testing that need to performed to ensure that the code is as bug-free as possible. I really got interested in writing unit tests after writing this book. The concept of Test Driven Development made a lot of sense and I will certainly try to incorporate this strategy into future projects. Most of the time explanations are consice, clear and to the point. Several open source frameworks such as EasyMock and DynaMock are introduced briefly - although the level of detail is not as good as I would like it to be, it is nevertheless good to know where to look for frameworks (that someone already developed) you might need for your projects.
The only downside to this book is that it is out of date. The JUNIT used in this book (3.8) is not the latest version available. I tested all of the code after downloading it from the web and I found that some of the samples did not work. In some cases, the software is dated. For example, in some chapters, the author uses Maven 1.0 instead of ANT as the build tool. However, for Maven to work, it needs to download several jar files from remote repository to the local repository on your machine. The very first time you run Maven, it is supposed to do this automatically for you before building your project; however, Maven 2.0 is out and the remote repository links with Maven 1.0 is broken which means that you need to download several jar files from google manually and put them in relevant folders - since there are several of them, I eventually gave up after doing a partial configuration. Note that the build files that use Maven 1.0 will not work with Maven 2.0 - you will need to do significant configuration changes in order to get this to work. I am new to Maven (although I am very experienced with ANT), so I did not bother with trying to get these code samples to work. The other thing I noticed is that some of the Cactus examples are not working in this book. In some cases, I had to do configuration changes and in others such as the chapter on unit testing the EJB, I was not yet able to figure out what went wrong. In any case, you can't simply expect to run the code and expect it to work especially in the later chapters!!! Be prepared to spend time to figure out what went wrong and how to fix it.
All in all, it is a nice book on introduction to unit testing and I will certainly recommend it to newcomers to this arena. Also, note that the level of detail and treatment provided in this book is not sufficient for real world projects. I am planning on getting a more advanced book (JUnit Recipies) to complete the picture.
The only downside to this book is that it is out of date. The JUNIT used in this book (3.8) is not the latest version available. I tested all of the code after downloading it from the web and I found that some of the samples did not work. In some cases, the software is dated. For example, in some chapters, the author uses Maven 1.0 instead of ANT as the build tool. However, for Maven to work, it needs to download several jar files from remote repository to the local repository on your machine. The very first time you run Maven, it is supposed to do this automatically for you before building your project; however, Maven 2.0 is out and the remote repository links with Maven 1.0 is broken which means that you need to download several jar files from google manually and put them in relevant folders - since there are several of them, I eventually gave up after doing a partial configuration. Note that the build files that use Maven 1.0 will not work with Maven 2.0 - you will need to do significant configuration changes in order to get this to work. I am new to Maven (although I am very experienced with ANT), so I did not bother with trying to get these code samples to work. The other thing I noticed is that some of the Cactus examples are not working in this book. In some cases, I had to do configuration changes and in others such as the chapter on unit testing the EJB, I was not yet able to figure out what went wrong. In any case, you can't simply expect to run the code and expect it to work especially in the later chapters!!! Be prepared to spend time to figure out what went wrong and how to fix it.
All in all, it is a nice book on introduction to unit testing and I will certainly recommend it to newcomers to this arena. Also, note that the level of detail and treatment provided in this book is not sufficient for real world projects. I am planning on getting a more advanced book (JUnit Recipies) to complete the picture.
Since this book I am a unit test enthusiast, 2006-09-28, Rating: 4.
Before reading this book I seldom wrote unit tests and when I just did it to make the project manager happy. I didn't really grasp what unit test is all about. I suppose many programmers in the industry know that unit testing is important. But they don't write any unit tests as it is boring and the next deadline is very close any way.
I started reading this book because a customer made me frustrated. He complained that stuff which worked in the last release doesn't work any more in the current release. This is of course a very unsatisfying situation. This stems from the fact that every software modification may lead to side effects. E.g. something which was OK before is now broken. Worst of all programmers don't know that something is not working any more. Programmers concentrate on what they are paid for and that is writing code. Most programmers are too optimistic as they assume that everything is working properly. And therefore they rarely test the same features again. How nice would it be to have "something" which tells the programmer that a feature is not working any more !
Well this "something" is called "Unit Testing". This book makes a good introduction to unit testing. It explains why you need less time to fullfill your tasks when you write unit tests and why there are fewer bugs. It is shown how stub and mock classes are used to break dependencies to other classes and other systems. It is pointed out how unit tests simplifies refactoring and how this leads to better design.
This refactoring approach is what me made enthusiatic about unit testing. Let's assume your task is to extend a poorly designed, undocumented application. The programmer who created this application left the company. So you have nothing else than undocumented code. What you do about it ? Well you can start writing unit tests to figure what the application does and how it works. Once you have a unit test suite you start refactoring and documenting the application. Thanks to your unit test suit you can perform the refactoring without fearing to break something which worked before.
Even though all examples are written in java the concepts and ideas layed out can be applied to other object oriented programming languages such as C++, VB.NET and C#.
However, this book fails to mention that unit testing is not a replacement for proper requirements engineering. Even with unit testing you still need to find an agreement with your customer on the features he wants to order.
Besides that, this book provides a good reading on a topic which will become even more important in the future. Let's hope that more programmers will read this book as this will improve software quality in this industry.
I started reading this book because a customer made me frustrated. He complained that stuff which worked in the last release doesn't work any more in the current release. This is of course a very unsatisfying situation. This stems from the fact that every software modification may lead to side effects. E.g. something which was OK before is now broken. Worst of all programmers don't know that something is not working any more. Programmers concentrate on what they are paid for and that is writing code. Most programmers are too optimistic as they assume that everything is working properly. And therefore they rarely test the same features again. How nice would it be to have "something" which tells the programmer that a feature is not working any more !
Well this "something" is called "Unit Testing". This book makes a good introduction to unit testing. It explains why you need less time to fullfill your tasks when you write unit tests and why there are fewer bugs. It is shown how stub and mock classes are used to break dependencies to other classes and other systems. It is pointed out how unit tests simplifies refactoring and how this leads to better design.
This refactoring approach is what me made enthusiatic about unit testing. Let's assume your task is to extend a poorly designed, undocumented application. The programmer who created this application left the company. So you have nothing else than undocumented code. What you do about it ? Well you can start writing unit tests to figure what the application does and how it works. Once you have a unit test suite you start refactoring and documenting the application. Thanks to your unit test suit you can perform the refactoring without fearing to break something which worked before.
Even though all examples are written in java the concepts and ideas layed out can be applied to other object oriented programming languages such as C++, VB.NET and C#.
However, this book fails to mention that unit testing is not a replacement for proper requirements engineering. Even with unit testing you still need to find an agreement with your customer on the features he wants to order.
Besides that, this book provides a good reading on a topic which will become even more important in the future. Let's hope that more programmers will read this book as this will improve software quality in this industry.
Great for JUnit - intro to intermediate topics, 2006-07-14, Rating: 4.
This book is a great intro to JUnit and quickly advances to intermediate level stuff (Cactus etc.). Lots of best practices are littered throughout the book and there's a good balance of code and discussion. A combination of this book with "Junit Recipes" by Rainsberger and "Java Development with Ant" by Hatcher will take you from newbie to JUnit guru in no time. Written in 2004 it's begun to get a little dated with JUnit 4.0 released (using annotations is quite a change) - however I'm sticking with JUnit 3.8 which this book is great for.
An ACTION packed thriller with JUnit. Must Read, 2006-04-22, Rating: 5.
First things first --> Test Driven(First) Development (TDD) is a *beaten to death* buzz phrase in the IT industry today. There are various proponents and opponents to this agile concept. Let me tell you that this book is neither a proponent nor an opponent to TDD, it just teaches you plain vanila unit-testing and how it will make you develop quality solutions.
Won't you agree if i say that we see or hear a few of the following during our typical work day.
1. JUnit, HttpUnit, DbUnit etc
2. Mock/Stub testing strategy
3. Repeatable tests, Continuous Integration
4. Innovative Testing frameworks like EasyMock, TestNG, Cactus etc
5. Designing and writing code for testability
Often, when we try to find out what exactly they are and how they are used in real projects, we are left with uninspiring documentation(if there is one) or we are left with a plethora of frameworks that do overlapping tasks. Without knowing *what, when and why's* of unit testing, we thrash it at the end of the day.
This book is an excellent resource in that it addresses the above questions and the questions that follow really well in a developer friendly manner.
1. Why to unit-test code? What advantages do you get by doing so? --> Quality, Confidence, Merciless Refactoring
2. What are the different types of tests that a software needs and how does unit testing fit into the overall picture? --> Unit, Integration, Functional and Acceptance tests
3. What is JUnit and how it fits into the unit-testing phase of our development process? --> Makes unit-testing a breeze
4. What tasks are not do-able with JUnit and how other frameworks and JUnit extensions address these issues? --> Cactus, EasyMock, HttpUnit, DbUnit etc
5. What are the different testing strategies that are available and when to use them? --> Stub, Mock, In-Container
6. What are the problems that you will encounter while unit testing and how to overcome them? --> Demotivation,
7. What are the different reasons that you will find to not do unit testing? Why and how to overcome them? --> Time Pressure, Not Applicable in my scenaro etc
8. How to test different types of artefacts? --> POJOs, Servlets, JSPs, Taglibs, Database Access, EJBs
9. How unit testing can be made fun? --> Profiling, metrics
10. All of these in a simple yet effective case study. --> Adminstration App.
There are a few *nice to have's* that this book missed:
1. Though it covers a lot of detail, i think the authors tried to cover too much ground in 350+ pages. Cactus was covered, but very superficially, particularly in the TestRunner area. I would expect greater detail in that area, because that is the most diffuclt part of cactus.
2. It would have been better if the authors concentrated more on *what to test* after the initial *how to test* chapters. I mean, since the authors are expert in this arena, it would have been better if they identified a few patterns on what gets commonly tested and put it forward to us. That would have been very useful.
Overall, this is a very well written book. The authors are not only technical experts, they are good writers as well. If you are even vaguely interested in trying out unit testing for your projects, you owe yourself to try this book and get enlightened.
Any program feature without an automated test simply doesn't exist. -- Kent Beck
Won't you agree if i say that we see or hear a few of the following during our typical work day.
1. JUnit, HttpUnit, DbUnit etc
2. Mock/Stub testing strategy
3. Repeatable tests, Continuous Integration
4. Innovative Testing frameworks like EasyMock, TestNG, Cactus etc
5. Designing and writing code for testability
Often, when we try to find out what exactly they are and how they are used in real projects, we are left with uninspiring documentation(if there is one) or we are left with a plethora of frameworks that do overlapping tasks. Without knowing *what, when and why's* of unit testing, we thrash it at the end of the day.
This book is an excellent resource in that it addresses the above questions and the questions that follow really well in a developer friendly manner.
1. Why to unit-test code? What advantages do you get by doing so? --> Quality, Confidence, Merciless Refactoring
2. What are the different types of tests that a software needs and how does unit testing fit into the overall picture? --> Unit, Integration, Functional and Acceptance tests
3. What is JUnit and how it fits into the unit-testing phase of our development process? --> Makes unit-testing a breeze
4. What tasks are not do-able with JUnit and how other frameworks and JUnit extensions address these issues? --> Cactus, EasyMock, HttpUnit, DbUnit etc
5. What are the different testing strategies that are available and when to use them? --> Stub, Mock, In-Container
6. What are the problems that you will encounter while unit testing and how to overcome them? --> Demotivation,
7. What are the different reasons that you will find to not do unit testing? Why and how to overcome them? --> Time Pressure, Not Applicable in my scenaro etc
8. How to test different types of artefacts? --> POJOs, Servlets, JSPs, Taglibs, Database Access, EJBs
9. How unit testing can be made fun? --> Profiling, metrics
10. All of these in a simple yet effective case study. --> Adminstration App.
There are a few *nice to have's* that this book missed:
1. Though it covers a lot of detail, i think the authors tried to cover too much ground in 350+ pages. Cactus was covered, but very superficially, particularly in the TestRunner area. I would expect greater detail in that area, because that is the most diffuclt part of cactus.
2. It would have been better if the authors concentrated more on *what to test* after the initial *how to test* chapters. I mean, since the authors are expert in this arena, it would have been better if they identified a few patterns on what gets commonly tested and put it forward to us. That would have been very useful.
Overall, this is a very well written book. The authors are not only technical experts, they are good writers as well. If you are even vaguely interested in trying out unit testing for your projects, you owe yourself to try this book and get enlightened.
Any program feature without an automated test simply doesn't exist. -- Kent Beck
Projects