Conference Presentations

Getting Started with Test Driven Development

Test-driven (or test first) development (TDD) is an excellent method for improving the quality of software applications. It forces the programmer to focus on ensuring that the behavior of the objects at the lowest level of the system is appropriate. It also provides a mechanism to ensure that future source code changes do not break existing behaviors. Using C++ as the example language, Robert Walsh presents an overview of test-driven development, available TDD testing frameworks, and a demonstration of a project started from scratch using TDD. You can apply these concepts to other languages, including Java and Visual Basic. Learn how to overcome the initial hurdles many developers experience when starting out with TDD.

  • An introduction to test-driven development using C++ as the example language
  • The testing frameworks available for TDD
  • Programming tasks that are difficult to implement using TDD
Robert Walsh, EnvisionWare, Inc.
Service-Oriented Architecture - Exposed

Service-Oriented Architecture (SOA), incorporating methods for Web services to communicate dynamically, promises to significantly improve organizational operating efficiency, change the way companies conduct business, and even alter the competitive landscape. However, Service-Oriented Architecture is a strategy rather than an objective, and, like any strategy, it is of no value unless it is implemented. With illustrations from companies who today are using SOA to transform their organizations, Sharon Fay shares current practices for exposing Web services and XML to internal development teams, outsourced development, external trading partners, and customers. Learn why reuse is a key method for supporting integration of SOA implementations and how it is being accomplished. Take away a set of metrics that you can use to measure the level of SOA adoption, development productivity gains, and organizational agility.

Sharon Fay, Flashline, Inc.
eXtreme Architecture and Design for Test

eXtreme programming emphasizes test-first coding-you write the tests before writing the implementation code. You can apply the same approach in design when developing a complex system, including an architecture to support testing. To be successful, systems developed with agile methods must support a high level of testability and test automation. For large distributed systems, more sophisticated testing is needed to help determine which components may be contributing to failures. For such complex systems, you should architect the system for testing rather than add testing functionality as an afterthought. Ken Pugh presents a framework that employs polymorphic-style internal and external interface patterns to ease the work of testing and debugging. He also covers adding test-only functionality, test-only outputs, and test-only logging to interfaces.

Ken Pugh, Pugh-Killeen Associates
GUI Usability Design and Validation with Paper Prototypes

Usability testing of early GUI designs with paper prototypes validates that you are building the right applications for your customers. This low-cost, high-impact practice allows you to rapidly evolve the GUI interface and find many design bugs early in the development process before coding begins. With this process, you can get external customers and internal users actively involved in designing and testing the GUI with tools they can easily manipulate. Based on project experiences at The MathWorks, Inc., you will learn how to move from the paper prototype to a coded GUI and a set of automated tests. In addition, you will learn to develop user documentation while working back and forth between the GUI and the test plan to clarify design choices.

  • Involving everyone in GUI design early in the project
  • User tasks and scenarios as the basis for GUI validation
Ann Walker, The MathWorks Inc
Refining Requirements with Test Cases

Requirements are supposed to be the basis of most test cases, but can you use test cases to define what the system needs to do--to improve or to actually become the requirements? To some degree, your development process dictates the opportunities you have for test cases to define or refine requirements. However, everyone can benefit from test case writing techniques to identify missing requirements, surface ambiguous statements, and expose implied requirements early in the process. Find out how Tanya Martin-McClellan produces test cases that accurately reflect the requirements, as they are understood at the time, and conducts team reviews to find the gaps and misunderstandings. Although more time is spent writing and rewriting test cases, less time is spent later discussing requirements.

  • Find the vaguely defined parts of the requirement definition
  • A template of implied requirements you can customize
Tanya Martin-McClellan, Texas Mutual Insurance Company
Expressing Requrirements as Users Stories - an Agile Approach

Expressing requirements as user stories is one of the most broadly applicable techniques introduced by eXtreme Programming and adopted by other agile development processes. User stories are an effective approach for capturing requirements from an agile project, not just those using XP. In this session learn what user stories are, how they differ from other requirements approaches, and why you should consider using them. You also will learn the six attributes all good stories must exhibit and see how to get started with user stories. Whether you are a developer, requirements analyst, tester, manager, or even a customer interested in applying agile techniques to your projects, this session is for you.

  • The differences between user stories and other requirements documentation
  • Attributes of "good" user stories
  • Examples of User Stories from agile development projects
Mike Cohn, Mountain Goat Software
Undoing Testing Methods in Agile Projects

The period 2002-2004 was one of enormous progress in figuring out how testing fits in on agile projects. Test-driven design is more about designing and writing the code than about finding bugs. New testing tools such as xUnit and FIT came out and received a lot of use by early adopters. The hopeful notion that customers would write acceptance tests to find bugs was expanded, challenged, and deepened. With all that progress, it's hard to be dissatisfied with these methods in agile projects. But past ways of thinking are holding us back. To make further progress, we have to split our notion of testing into two parts: the task of after-the-fact product critique, and a role that has nothing at all to do with bugs and, really, little to do with the word "testing." Brian Marick, a founding member of the Agile Alliance, explains what that role presents and some ideas on how to fill it.

Brian Marick, Testing Foundations
Design Patterns in Test Driven Development

Design patterns are powerful tools when understood and employed properly. Combining design patterns and test-driven development (TDD) using a set of design principles will achieve higher productivity and quality than either practice alone. With numerous code snippets as examples, Thirumalesh Bhat describes the design principles and resulting patterns that have been extracted from TDD practices at Microsoft. Learn more about these design principles: commonality/variability analysis, open/closed principle, high cohesion, low coupling, prototyping, designing for current features, single point of maintenance, refactoring, unit testing, testability, and cost/benefit analysis. Adapt and apply these principles and design patterns to your TDD projects for the same benefits.

  • Fundamental principles of design patterns
  • Test-driven development (TDD) and refactoring
Thirumalesh Bhat, Microsoft Corporation
Design Testability and Service Level Measurements into Software

Design and architecture decisions made early in the project have a profound influence on the testability of an application. Although testing is a necessary and integral part of application development, architecture and design considerations rarely include the impacts of development design decisions on testability. In addition, build vs. buy, third party controls, open source vs. proprietary, and other similar questions can affect greatly the ability of an organization to carry out automated functional and performance testing-both positively and negatively. If the software or service is delivered to a separate set of end-users who then need to perform testing activities, the problems compound. Join Jay Weiser to find out about the important design and architecture decisions that will ensure more efficient and effective testability of your applications.

Jay Weiser, WorkSoft
Patterns for Writing Effective Use Cases

Use cases are a wonderfully simple concept: document a system's functional requirements by writing down scenarios about how using it delivers value to its actors. However, writing effective use cases is more difficult than expected because you frequently must deal with difficult questions, such as: scope, level of detail needed for different people and projects, how to describe external interfaces, stored data, and more. You need a source of objective criteria to judge use case quality and effectiveness. Fill this critical information gap with a pattern language that provides simple, elegant, and proven solutions to common problems in use case development. Take away these use case patterns and profit from the knowledge and experience of other successful use case writers. And develop a new vocabulary for describing the properties of quality use cases.

  • The "signs of quality" and properties of a good use case
Steve Adolph, WSA Consulting Inc.

Pages

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.