Testing Object-Oriented Systems: Models, Patterns, and Tools (Arp/Aod) (Paperback)

by Robert V. Binder and Róbert Binder

Book Overview

More than ever, mission-critical and business-critical applications depend on object-oriented (OO) software. Testing techniques tailored to the unique challenges of OO technology are necessary to... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0321700678
• ISBN13: 9780321700674
• Release Date: January 1999
• Publisher: Addison-Wesley Professional
• Length: 848 Pages
• Weight: 1.41 lbs.
• Dimensions: 2.5" x 7.1" x 9.1"

Customer Reviews

A book with good basics of software testing

This book gives solid view of basics of software testing. This book covers theory as well as practical examples. All the topics are covered in details touching all the aspects of the software testing. This a very good reference book for Software Testing.

Great coverage of OOP testing

This book is an excellent source for the novice and the experienced SQA Engineer. It covers most aspects of SW testing at a very practical level. Explanations and illustrations are well focused and the code samples can save you many hours of design and implementation time. The theory provies a solid foundation, important to do serious QA.

A "must have" testing reference.

This book is invaluable. Yes, it is large, but the topic is large, and this incredible book covers it so thoroughly. It is also extremely readable, with no skimping on the practical examples. The book is filled with test design patterns, and a variety of testing related procedures, all ready for implementation. The material on testing strategies based on fault-models is priceless, and is applicable outside the OO paradigm.I developed software for 12 years in a "testing-by-use-cases" company. Over 50% of the bugs coming out of our system tests were unit test problems! Argh! I can't wait to start using the great stuff in this book. An example: a table in Chapter 8 lists the various UML diagrams and how they can be related to test design patterns.If you play any role in the development of OO software, you need this book. And if Chapter 4, which points out exactly the problems that come with OO software and how to make the necessary changes to manage them, and section 2.3 "FAQs for Object-oriented Testing" do not convince you to take a new look at your approach to testing, you are probably beyond hope. A spot has already been reserved on my bookshelf for the promised companion volume.

A true practical book on ttest subject

I read many books on tests (and tried to apply concretely), and I find this book on the top of those ones. The second one could be "automated software testing" from [dustin+] which is complementary and then "black box testing" [beizer] . The worst one could be certainly " managing the testing process" [black] regards, xavier mehaut

A necessary book, but will the right people read it?

A book like this is intimidating. At close to 1000 pages it is no lightweight reading matter. However this book is an engineer's approach to the concept of testing object systems and it should be a standard reference for OO developers. Object-oriented languages, while recognised as a clear forward step in programming technology, introduce new ways for defects to be introduced. Inheritance and polymorphism both are powerful concepts, but also carry the potential for insidious defects. This book introduces fundamental techniques to analyse the class design and derive appropriate tests for its behaviour. I regard Bob's book as a must for developers. However I wonder if they will read it. This is not a criticism on this book, quite the contrary. My concern is related to the insight that most programmers see unit testing as an afterthought and not as a major component of their work. Often unit testing is seen as difficult, because of the complexities of class behaviour. And it is so easy to pass this burden on to system testing. My message for developers is, make the attempt to read it! It actually makes it easier to design and implement unit testing. It also pays off. You will have less requests for bugfixes coming back from testing. It has been long my contention that it is in the interest of the testing community to get out of its own trenches and start working closely with developers, making it easy for them to implement effective unit testing. This book is a good start in this direction.