SPA Conference session: Tackling the Encapsulation – Testability Tradeoff | |||
| One-line description: | We will explore existing and future solutions for testability, which developers often find conflicts with their goals of encapsulation. | ||
| Session format: | Workshop (75 mins) [read about the different session types] | ||
| Abstract: | As automated testing seems to progressively proliferate – not the least due to the popularizing of TDD – testability is gaining the attention of developers everywhere: Many developers struggle with the mechanics of creating designs that are testable, and others with refactoring existing designs in order to introduce unit tests. As part of this learning process developers encounter some of the tradeoffs between different aspects of software quality and design that have to be made. The tradeoff between making code testable, and what developers intuitively feel is a well encapsulated design is one such tradeoff that almost everyone face at some point. A testament to this and other related conflicts can be found in many forums, that discuss TDD and other practices that require testability. These two concepts are fascinating since they are both concrete and abstract at the same time, and like games, philosophies and many principles they take but a minute to understand yet a lifetime to master. In this session we will review the concepts of testability and encapsulation, based on now classic definitions in software engineering and also more recent research. A summary of how these somewhat abstract concepts can be mapped to concrete aspects of code will be presented, as well as examples of conflicts and what solutions that are employed today. We will then discuss and share differing views on the concepts and how they can be used to resolve the conflicts. We may arrive at some useful heuristics that can be applied today, or perhaps some ideas for future tool enhancements. At the very least, we will gain a valuable deeper understanding and appreciation for testability, its relationship with design and code in general, and encapsulation in particular. | ||
| Audience background: | Architects, designers, developers and software test engineers either proficient or starting with test based development methods (such as TDD/BDD) or testing. Since the issues are basic and foundational, any professional with experience that finds the subject interesting will likely be able to contribute part in a meaningful way, however, the theoretical material will cover many aspects related to TDD and testing in a review manner that assumes previous exposure and understanding. One of Java/C#/C++ experience recommended. Code will be in C# but java will also be adressed. | ||
| Benefits of participating: | • Understand the finer points of testability and encapsulation • Become aware and prepared for conflicts between them and other testability tradeoffs • Gather strategies to pragmatically resolve these conflicts in a context sensitive way | ||
| Materials provided: | • Presentation slides • Cases and designs for the discussions (3-5 cases/designs, TDB) | ||
| Process: | 1. Initial coverage of the theory: a. Review of testability, formal definitions as well as practitioners definitions b. Mapping of testability to concrete requirements of OO code c. Review of encapsulation and its purposes 2. In groups: Case analysis and concept reflection We split ourselves into smaller groups, discuss the topics, and share experiences: We look at some simple designs with their case contexts specified and explore our perceptions of the concepts, their context dependence and if/how our understanding of them has changed, as our development practices have changed. 3. We summarize the findings of the different groups on the designs presented: Where was encapsulation evident and what purpose did it serve? Where the designs testable? Would improving testability appear to conflict with any encapsulation goals? 4. Some further material regarding the relationship between testability and encapsulation is presented, reviewing strategies that are currently employed to meet encapsulation goals while opening up for tests. 5. In groups: Discussion of strategies, limitations and future ideas and improvements. The presented strategies are discussed and their merits are discussed. Questions revolve around design priorities and tool limitations: Do presented strategies map neatly to different design goals? Is there need for further tool support or are available language constructs sufficient? 6. Summary of findings are presented by the groups | ||
| Detailed timetable: | |||
| Outputs: | A text as web page summarizing findings such as: • Different approaches and recommendations for the tradeoffs • List of important factors in the tradeoffs • Mapping of strategies to design goals • Possibly: Ideas for further tool support | ||
| History: | None, the session is new. However, it is focusing on some topics from a breakfast seminar held in Malmö in Feb 2006, and a session to be held at the Oredev conference in November 2006. It is based on the content of an article yet to be published, titled “Improving testability while maintaining encapsulation”, available on request. There is naturally room for editing this proposal, and since it is new I will probably test run it one or two times internally, in order to test content and schedule. | ||
| Presenters | |||
| 1. Marcus Widerberg Dotway |
2. | 3. | |