Abstract: From the Book: Extreme Programming sounds great—can we do it without changing our process? When I first heard about Extreme Programming in May 1998 I could see that it was going to be controversial. It was immediately obvious from the wide range of reactions that were expressed to two talks given by Kent Beck and Ron Jeffries at a seminar on “Developing Software with Objects” in Oslo. (Hosted by Den Norske Dataforening on 13 May, 1998) Many developers seemed to be attracted to it, but others in the room challenged the ideas and concepts behind Extreme Programming. Personally my reactions were mixed. It sounded like it would be a fun approach to software development and it didn’t sound like it was applicable to the kinds of projects that I was involved in. Admittedly, my initial reservations were about how easy it would be to sell the approach, but as I inquired deeper into Extreme Programming I came to realize that there are fairly stringent preconditions for teams that wish to adopt and use XP. It seems to me that many of the reactions to Extreme Programming can be explained by the fit between these preconditions and the particular project circumstances that a person has experienced. This book sets out to question Extreme Programming in an attempt to understand and explain the controversy that surrounds Extreme Programming. My goal for this book is to allow you, the reader, to determine if Extreme Programming is applicable and appropriate for your projects, to investigate what lessons can be learned from Extreme Programming and to enable you to be more reflective about your software development practices. Before getting down to that I must firstexplain my biases. As a developer I am attracted towards the ideas behind XP, mainly because most of the developers I have talked to that have worked on XP projects have really enjoyed the experience. I am also a strong fan of XP style unit testing and have introduced JUnit (www.junit.org) to many project teams. Although I have never worked on a full XP project, I have worked in a team that initially claimed that it was going to be doing XP, but actually turned out to be doing something that was vaguely related to some of the XP practices. As much as is possible I have tried to present both sides of the debate surrounding Extreme Programming without getting into the continual flame-fest that discussions on usenet newsgroups and email lists often contain. I have written this book as a practical guide for four different audiences: people who are thinking of adopting Extreme Programming people who are resisting the idea of adopting Extreme Programming, people who are looking for alternatives to Extreme Programming people who are interested in improving their current software development process As a practical guide this book is focused on identifying issues surrounding software development and discussing how Extreme Programming interacts with these issues. As this is a practical guide, you will not find much in the way of detailed studies and experimental data. This book focuses on clarifying the issues so that you, the reader, can determine the fit between Extreme Programming and your specific circumstances. Adopting Extreme Programming All processes are situational. Software development is not a mechanical process and as such you will never be able to adopt a process without doing some adapting to fit with your circumstances and team. Before adopting Extreme Programming you need to have a deep understanding of the values that drive it so that the adaptations you make match the overall spirit of XP. This book looks back to the roots of XP to enable you to understand the underlying software development issues so that you can better assess how XP will fit your organization. This book will also expose you to alternate approaches that might be a better fit. Resisting Extreme Programming Extreme Programming is a different kind of software development process, it is one that many programmers actually want to use. All too often however this means that some programmers end up pushing the idea of adopting XP when for one reason or another it does not really fit the organization. This book provides the questions you need to ask to determine whether XP really does fit the needs and circumstances of your organization. Hopefully it will also allow you to identify the issues with your current process that caused XP to be raised as a potential alternative in the first place. Then, rather than shooting the messenger or dismissing the message, the book asks the question “What can we learn from XP?” Looking For Alternatives To Extreme Programming Extreme Programming is a great fit for some projects and organizations, but one size does not fit all. There are many other software development approaches, and with all of the exposure that Extreme Programming is getting, these alternatives are getting somewhat lost. Using an Agile Methodology does not necessarily mean using Extreme Programming. Questioning Extreme Programming attempts to uncover the issues that are driving the creation of new approaches to software development. By exposing these issues I hope to spur software developers and their managers to create alternative approaches that build on the strengths of Extreme Programming while incorporating the strengths of the other approaches. Improving Your Current Software Development Process Adopting a new software development process can be hard. The organization has to learn how to effectively apply the new process and there is the transition period when some projects are using the new process while the rest are still using the old process. Sometimes it just makes sense to retain your existing process and to try to improve it by dropping parts, changing parts and adding new parts. By continually asking the question “What can we learn from XP?” this book highlights different ideas that could potentially be applied within the context of a different process. The resulting hybrid will not be XP, but then again, that is not the goal. By adopting the Extreme Programming mindset of continually reflecting on, and tinkering with, the process, you open up the possibility of creating your own optimized process. Why You Should Read This Book The way that we develop software is changing. Yes, people have always claimed that the IT industry has been a real driver for change, but until recently that change has only really shown up in the hardware and software. The way that we develop software has been remarkably resistant to change. Indeed Watts S. Humphrey spoke for many methodologists in his article, “Why Don't They Practice What We Preach? ” when he said “One of the most intractable problems in software is getting engineers to use effective methods.” http://www.sei.cmu.edu/publications/articles/practice-preach/practice-preach.html Many proponents of Extreme Programming would claim that the problem is no longer intractable - lots of programmers would jump at the chance of using XP. Indeed many developers are very keen to experiment with and try out new ways of developing software. It seems as if developers are beginning to see that things have changed. Jim Highsmith probably summed this up best when he said “We must challenge our most fundamental assumptions about software development.” Highsmith, 2000, p13 Questioning Extreme Programming invites you to take up that challenge. Acknowledgments First I would like to thank Kent Beck, Ward Cunningham and Ron Jeffries for starting the conversation around eXtreme programming. If nothing else they have managed to make software development methodologies interesting again. As usual, the team at Addison-Wesley was extremely supportive and enthusiastic about this project–Ross Venables, Mike Hendrickson, et. al. My reviewers seemed particularly gleeful this time, and although one expressed regrets that the book is not the flame-fest material he hoped for, all helped me to clarify my thoughts about Extreme Programming–Alastair Handley, Andy Hunt, Dave Thomas, Greg Klafki, Jens Coldewey, Jim Highsmith, Kent Beck, Miroslav Novak, Ron Jeffries and Rudy Wrench.

Abstract: Testing and refactoring are core activities in extreme programming (XP). In principle, they are separate activities where the tests are used to verify that refactorings do not change behavior of the system. In practice however, they can become intertwined when refactorings invalidate tests. This paper explores the precise relationship between the two. First, we identify which of the published refactorings affect the test code. Second, we observe that if test-first design is a way to arrive at well-designed code, “test-first refactoring” is a way to arrive at a better design for existing code. Third, some refactorings improve testability, and should therefore be followed by improvements of the test code. To emphasize this, we propose the notion of “refactoring session” which includes changes to the code followed by changes to the tests. To guide the developer in the steps to take, we propose to extend the description of the mechanics of individual refactorings with consequences for the corresponding test code.

Abstract: The problem of testing modular systems against algebraic specifications is discussed. We focus on systems where the decomposition into parts is specified by a Casl-style architectural specification and the parts (units) are developed separately, perhaps by an independent supplier. We consider how to test such units without reference to their context of use. This problem is most acute for generic units where the particular instantiation cannot be predicted.

Abstract: The problem of testing modular systems against algebraic specifications is discussed. We focus on systems where the decomposition into parts is specified by a CASL-style architectural specification and the parts (units) are developed separately, perhaps by an independent supplier. We consider how to test such units without reference to their context of use. This problem is most acute for generic units where the particular instantiation cannot be predicted.

Abstract: A computer system executing a method for performing reusable software application development comprises integrating a data processing system, providing a set of keywords and attributes, and declaring a set of executable specifications using the keywords and attributes, further comprising generating a program code, instantiating an object code, generating a testable functionality result, generating at least one unit test, generating an implementation documentation output, generating a performance statistics output, and generating a project metrics in the data processing system. The step of providing a set of keywords and attributes comprises generating a set of user interface forms, fields, and validation rules, generating a library of structured query language statements, generating a library of rules for generating dynamic structured query language statements, generating one of a web browser report, a file-based report, and a portable document format report, generating a library of security rules and permission statements, and generating database schemata.

Abstract: Unit testing is one of the core practices in the Extreme Programming lightweight software development method, and it is usually carried out with the help of software frameworks that ease the construction of test cases as an integral part of programming tasks. This work describes our first results in studying the integration of automated unit testing practices in conventional 'introduction to programming' laboratories. Since the work used a classical procedural language in the course's assignments, we had to design a specific testing framework called tpUnit. The results of the experiment points out that a straightforward approach for the integration of unit testing in first-semester courses do not result in the expected outcomes in terms of student's engagement in the practice.

Abstract: In this paper we explore frameworks for performing unit testing in Java. The vehicle for this exploration is a student-written, skeleton program developed for the Computer Graphics course. Our analysis of this one experiment leads us to speculate what benefits in program development and design might accrue by requiring students to unit test their own programs.

Abstract: One thing that makes unit-testing code so hard is the way the real world keeps intruding. If all we had to do was code up tests for methods that sort arrays or generate Fibonacci series, life would be easy. In the real world we have to test code that uses databases, communications devices, user interfaces, and external applications. We might have to interface to devices that are not yet available or simulate network errors that are impossible to generate locally. This all conspires to stop our unit tests from being neat, self-contained (and orthogonal) chunks of code. Fortunately there is a testing pattern that can help. The authors consider the use of mock objects. With mock objects you can test code in splendid isolation, simulating all those messy real-world things that would otherwise make automated testing impossible. As with many other testing practices, the discipline of using mock objects can improve your code's structure.

Abstract: A semiconductor memory device and a method for testing the same which optimizes operation conditions by detecting a test cell that may easily fail in a test among the memory cells passing a burn-in test, and detecting the worst operation conditions by performing the test on the test cell. The device and method reduce power consumption in a refresh or active operation. According to the device and method set forth, a test unit tests a test cell, controls operation conditions of the semiconductor memory device according to the test result, and outputs the operation conditions. A driving unit drives the semiconductor memory device using the operation conditions controlled by the test unit.

Abstract: Class testing is the base of object-oriented software testing. It involves three aspects: testing each method, testing the relations among class methods and testing the inheriting relation between class and subclass. Rather than concerning the whole class testing process, most specification-based class testing focuses on the methods of generating test cases from the class specification. As a result, the class testing process and test cases cannot be unified and managed in a consistent and convenient way. This paper introduces a test class framework (TCF) that is used to structure the test cases and test deriving process of the class under testing. This framework clearly denotes the process of deriving test cases and test suites from a class specification. It facilitates the construction and management of test cases. Object-Z notation is used to express the framework and class specification.

Abstract: The invention relates to a method and device for operating and/or testing memory units, which make it possible to conduct a time-saving test of semiconductor memories during running operation. The inventive method for testing memory units (2) having storage locations (1) provides that, for the storage locations (1), a first item of test information is formed according to a variable parameter assigned to the respective storage location (1) and according to the contents of the respective storage location (1).

Abstract: The problem of testing modular systems against algebraic specifications is discussed. We focus on systems where the decomposition into parts is specified by a CASL-style architectural specification and the parts (units) are developed separately, perhaps by an independent supplier. We consider how to test such units without reference to their context of use. This problem is most acute for generic units where the particular instantiation cannot be predicted.

Abstract: Within component based (CB) software development, testing becomes a crucial activity for interoperability validation, but enabling test execution over an externally acquired component is difficult and labor-intensive. To address such problem, we propose the WCT component, a generic test wrapper that dynamically adapts the component interfaces, making the test execution independent from any specific component implementation. The wrapper does not require that the component implements any specific interface for testing purposes, it permits to easily reconfigure the subsystem under test after the introduction/removal/substitution of a component, and helps optimize test reuse, by keeping trace of the test cases that directly affect the wrapped component.

Abstract: In modern software development a lot of time is spent on testing. Nevertheless it is commonly agreed that testing is almost never done well enough. This paper presents a new approach to software testing called Testing by Contract. The new approach builds on top of a couple of well-known techniques especially Design by Contract as known from Eiffel and Unit testing as known from Extreme Programming. The basic idea is to reuse the assertions written as part of Design by Contract in Unit test cases. To provide test data the idea of a Testable interface is presented. The interface uses the notion of equivalence partitioning. The paper sketches how a concrete tool for Testing by Contract could be build. The main argument for using Testing by Contract is that if the programmer provides an implementation of the Testable interface together with preand post-conditions and class-invariants, a number of test cases and test result come for free. This paper is work in progress and the development of a prototype of a Testing by Contract tool has been started, but no results are available yet.

Abstract: An electrical assembly testing device includes the capability of testing for specific components of interest. A sample component and the component of interest receive a test signal from a test signal generator. An output from each component in response to the test signal is utilized by a controller to determine a relationship between the outputs. The determined relationship between the outputs provides information regarding the component of interest so that the controller can make a determination whether the component is acceptable or whether it fails to meet selected criteria. In one example, a device designed according to this invention is particularly well suited for testing capacitors within wire harness assemblies.

Abstract: Students in two offerings of a software engineering course were asked to write opinion papers regarding the use of Extreme Programming (XP) in an undergraduate computer science curriculum. The majority opposed the use of XP as the preferred life-cycle model for the project in that course, but they did support introducing some of the practices of XP in selected courses. They felt that unit testing and coding standards should become part of the introductory programming courses, but other practices should be deferred to specific project-oriented courses, or not introduced at all. Two pilot studies provided additional insights that are consistent with the students' opinions.

Abstract: Component-Based Software Engineering has the potential to provide reliable systems based on tested components quickly and economically, but these systems will only be as reliable as the components from which they are constructed. We propose a 6-point scale which can be used to rate the degree to which a component has been tested. This scale can be used by developers to assess the risk of using a third party component. Since a variety of test strategies are used, it is necessary to correlate testing strategies with our scale. In this paper, we examine the testing strategies specified in British Standard 7925-2 and show how they relate to the reliability levels that we propose. Since well-behaved use of resources is also a key factor in overall system reliability, we propose that an 'R' tag be added to the rated level when resource usage has been verified to be within reasonable bounds.

Abstract: Much of software engineering is targeted towards identifying and removing existing defects while preventing the injection of new ones. Defect management is therefore one important software development process whose principal aim is to ensure that the software produced reaches the required quality standard before it is shipped into the market place. In this paper, we report on the results of research conducted to develop a predictive model of the efficacy of one important defect management technique, that of unit testing. We have taken an empirical approach. We commence with a number of assumptions that led to a theoretical model which describes the relationship between effort expended and the number of defects remaining in a software code module tested (the latter measure being termed correctness). This model is general enough to capture the possibility that debugging of a software defect is not perfect and could lead to new defects being injected. The Model is examined empirically against actual data and validated as a good predictive model under specific conditions. The work has been done in such a way that models are derived not only for the case of overall correctness but also for specific types of correctness such as correctness arising from the removal of defects contributing to shortcoming in reliability (R-type), functionality (F-type), usability (U-type) and maintainability (M-type) aspects of the program subject to defect management.

Abstract: In Extreme Programming, unit testing is an integral activity of everyday software development For isolating units in the tests, Mock Objects are often used to simulate collaborators of the units under test However, writing and maintaining Mock Objects may become a tedious task This paper presents the Java library EasyMock that dynamically generates Mock Objects for interfaces This moves the specification of the Mock Objects into the test methods, avoids implementation mistakes, and eases refactoring

Abstract: Invited Talk 1.- Semantic Models for Distributed Object Reflection.- Aspect Oriented Software Development.- AOP: Does It Make Sense? The Case of Concurrency and Failures.- Difference-Based Modules: A Class-Independent Module Mechanism.- Dynamically Composable Collaborations with Delegation Layers.- Java Virtual Machines.- Space- and Time-Efficient Implementation of the Java Object Model.- Atomic Instructions in Java.- Code Sharing among Virtual Machines.- Miscellaneous.- J-Orchestra: Automatic Java Application Partitioning.- Supporting Unanticipated Dynamic Adaptation of Application Behaviour.- A Simple and Practical Approach to Unit Testing: The JML and JUnit Way.- Invited Talk 2.- Objectively: Components versus Web Services.- Distributed Systems.- Modular Internet Programming with Cells.- Lana: An Approach to Programming Autonomous Systems.- Engineering Event-Based Systems with Scopes.- Patterns and Architecture.- Architectural Reasoning in ArchJava.- Patterns as Signs.- Pattern-Based Design and Implementation of an XML and RDF Parser and Interpreter: A Case Study.- Languages.- Modern Concurrency Abstractions for C#.- On Variance-Based Subtyping for Parametric Types.- Type-Safe Prototype-Based Component Evolution.- Optimization.- Thin Guards: A Simple and Effective Technique for Reducing the Penalty of Dynamic Class Loading.- Type-Safe Method Inlining.- Polychotomic Encoding: A Better Quasi-Optimal Bit-Vector Encoding of Tree Hierarchies.- Theory and Formal Techniques.- Semantics-Based Composition of Class Hierarchies.- Behavioral Compatibility of Self-Typed Theories.- A Formal Framework for Java Separate Compilation.

Abstract: A preburning controller of integrated circuit (IC) is composed of several unit test boards and a region distributing board. Said unit test board consists of a test pattern generator for generating test pattern to the module to be tested for determining if the several ICs contained in said module are valuable and a module to be tested. Said region distributing board is used to control at least onetest pattern generator on one unit test board and receive its test result. Its advantages are high speed of generating test pattern and high anti-interference power.

Abstract: The THROHPUT code, which models transient thermohydraulic heat pipe behavior, is being incorporated into the CAESAR computational physics development environment. The CAESAR environment provides many beneficial features for enhanced model development, including levelized design, unit testing, Design by ContractTM (Meyer, 1997), and literate programming (Knuth, 1992), in a parallel, object-based manner. The original THROHPUT code was developed as a doctoral thesis research code; the current emphasis is on making a robust, verifiable, documented, component-based production package. Results from the original code are included.

Abstract: From the Publisher: JSP Examples and Best Practices takes basic JSP and applies sound architectural principles and design patterns to give the average developer the tools to build scalable enterprise applications using JSP. While other books provide instruction on basic JSP and servlet development, JSP Examples and Best Practices gives developers several best practices and design principles to enable them to build scalable and extensible enterprise Java applications. Through the application of enterprise design patterns, JavaServer Pages technology can be used to build complex enterprise applications in a highly re-usable manner. Early JSP applications followed the "model 1" pattern for JSP development, consisting of several pages of HTML and Java code intermixed. Several common functions were hard-coded in several places throughout the pages. As of late, developers have begun applying the "model 2" pattern for JSP development, following more of a standard Model-View-Controller (MVC) approach. Andrew Patzer takes this to a new level by applying enterprise design patterns to create a powerful request-handling framework built upon the MVC model. A framework would not be very useful if it were left by itself. JSP Examples and Best Practices augments the framework with unit testing, load testing, and automated build procedures using open source tools from the Apache group. Author Information Andrew Patzer is a web architect for a consulting firm located in the Midwest. His first book, Professional Java Server Programming, is a best seller and one of the first books to cover J2EE technologies. Andrew recently served as a lead systems architect for an industry leading application service provider in the insurance industry. He was directly involved in designing and building a J2EE development framework upon which the company's key product was built. Andrew has delivered several presentations over the years to both local user groups as well as national conferences. Author was the principal author of the best-selling Professional Java Server Programming-among the first to cover J2EE technologies Includes best-practices, enterprise design patterns, and architectural constructs to provide unit testing, load testing, and automated deployment procedures Covers new features of the JSP 1.2 specification including the standard filtering mechanism

Abstract: PROBLEM TO BE SOLVED: To provide an automatic unit testing system capable of handling an interruption processing and bit data and provided with functions for setting an initial value to a variable, perfing a type definition independent of a processor, coping with an alias variable and outputting performance information, etc. SOLUTION: An automatic unit testing is realized by a continuous test pattern execution system 2b having a command string generating part 2c, an instruction set simulator 2d and an output forming part 2e by providing description 22 to cope with interruption, description 25 to cope with bit, initial value setting description 27 and processor independent type definition 28 in a test pattern file 21, coping with an object function to require interruption of a source program file 18 by description of a pragma 24 for generating interruption and simulation 23 of timer/external interruption and adding an alias definition file 29 to the object function. The performance information 2a is outputted as the result of execution of the automatic unit testing.

Abstract: Unit tests are tests of code modules by the programmers who created them Acceptance tests are tests of software functionality from a customer, or user, perspective Both types of tests are important Tools and practices to support and encourage unit testing on extreme programming and other agile projects are well-developed and well-documented This workshop discusses and develops practices for supporting acceptance testing on agile projects (Some refer to acceptance testing as system or functional testing GUI testing is a common approach)

Abstract: We present an application that allows for easy creation of simple problem solving exercises in Java, providing robust and safe I/O as well as a basic graphics window. We discuss possible uses for unit testing of classes and explore how the design of this application can be a case study in an object oriented design course.

Abstract: approved: _______________________________________________________ Mentor’s Name (no titles) This study intended to investigate two areas of end-user programming: the influence of individual differences on success and whether or not groups of programming, testing, and debugging style would naturally cluster together and provide predictive value. Eighty-six participants, from backgrounds of computer science, psychology, engineering and humanities completed at battery of psychological tests and attempted to complete a timed programming task and testing and debugging task in Stata, a statistical programming environment intended for use by individuals with no programming experience. General intelligence and programming experience were good predictors of programming success. Three types of programming strategies were found: (1) the programmers group used their background knowledge to solve the programming task with little effort; (2) the lost/unmotivated group tended to exhibit repetitive and shallow problem solving; (3) the lost/motivated group tended to search for more information and exhibit more guess and check behavior. There were three types of testing and debugging strategies, but no good predictors of success: (1) the curious/distracted group ignored the task and became distracted; (2) the hesitant/focused group sought little information and made few attempts to debug; (3) the active/focused group sought much information and made many attempts to debug. Future work on the data presented here is proposed.

Abstract: PROBLEM TO BE SOLVED: To standardize test density by creating a test item form by automatically extracting test items from a newly created source file including revision to be inputted. SOLUTION: In this method for supporting creation of a unit test item form to perform a unit test of a program and its system 1, the newly created input source file 2 including the revision is obtained as input, individual functions to constitute the input source file 2 are made into blocks by any of a part to be processed according to conditions, an initialized part including a declaratory sentence and a part to be bundled by dead letters (a blocking part 11) and the unit test item form 3 is created by extracting the test items by the unit of the block (a unit test item form creating and processing part 12).