There’s no science fiction here; our papers illustrate some of the valuable, practical approaches we’ve learned over time.
The mock object approach to test-driven development
October 16, 2012
A guide to implementing test driven development methods for your embedded systems using mock objects, whether or not you are doing your design in the C language or in C++.
Agile Project Management. Or, Burning Your Gantt Charts.
Embedded Systems Conference 2008
Boston, MA, USA
Michael Karlesky and Mark Vander Voord
Embrace change. Schedules, budgets, competitive environments, and requirements change. Unanticipated, difficult problems are discovered during development. Traditional embedded project management usually hinges on eliminating change and designing out uncertainty up-front; such an approach is fantasy. Agile Project Management offers solutions to common, persistent problems: poor estimates, slipped timelines, products languishing in an almost-done state, and Gantt charts rarely reflecting reality. Here we discuss: usable definitions of “customer”, “feature” and “done”; prioritization; iterations; estimation; burndown charts; documentation; and risk & scope management.
Feature-Driven Design Using TDD and Mocks
Embedded Systems Conference 2008
Boston, MA, USA
Greg Williams and Mark Vander Voord
Top-down design has long been talked about as a very efficient way of developing an embedded system. Although, many attempts at actually implementing a real product in this fashion has led to disaster since code interacting from a high-level down to a low-level interface to hardware registers begs to know how to interface to these hardware layers, thus sending the developer on a downward spiral toward implementing a bottom-up design, unfortunately breaking the original intent. We present a design methodology, Feature-Driven Design, that focus on the implementation of features instead of modules of code that gives way to architectures that evolve naturally and are much easier to understand and maintain. This way of development is fueled by unit test frameworks and automatically generated mocks, so that that designs can materialize from high level ideas and iterative refinement.
Evolving into Embedded Development
Washington, DC, USA
Matt Fletcher, William Bereza, Mike Karlesky, and Greg Williams
In late 2005 we had the opportunity to start our first embedded development project. We apply agile practices to a variety of domains from web development to desktop applications to factory floor test equipment. The challenge for this new work was not learning the environment and technology. Our challenge was applying the practices of the agile world to the small and complex world of embedded systems. The hurdles were numerous: we battled the archaic state of many embedded tool sets, the lack of integration with tools like Rake that provide easy automation, and poor support for object oriented design. We’ve overcome each of these difficulties. This report is about our yearlong experience in introducing our development practices to embedded development.
Mocking the Embedded World: Test-Driven Development, Continuous Integration, and Design Patterns
Embedded Systems Conference Silicon Valley
San Jose, California, USA
M. Karlesky, G. Williams, W. Bereza, and M. Fletcher
Despite a prevalent industry perception to the contrary, the agile practices of Test-Driven Development and Continuous Integration can be successfully applied to embedded software. We present here a holistic set of practices, platform independent tools, and a new design pattern (Model Conductor Hardware – MCH) that together produce: good design from tests programmed first, logic decoupled from hardware, and systems testable under automation. Ultimately, this approach yields an order of magnitude or more reduction in software flaws, predictable progress, and measurable velocity for data-driven project management. We use the approach discussed herein for real-world production systems and have included a full C-based sample project (using an Atmel AT91SAM7X ARM7) to illustrate it. This example demonstrates transforming requirements into test code, system, integration, and unit tests driving development, daily “micro design” fleshing out a system’s architecture, the use of the MCH itself, and the use of mock functions in tests.
Big, Complex, and Tested? Just Say ‘When’
Published in Better Software, February 2007
David Crosby, Carl Erickson
“Atomic Object developers have hammered out a method of software development that bridges the language gap between code and customers, opens the door wide to test-driven development, works with many domains and languages, scales to complex applications, and, once mastered, can be practiced with almost mechanical repetition. We use an approach called ‘Presenter First’... and we think you can use it, too.”
Presenter First: Organizing Complex GUI Applications for Test-Driven Development
M. Alles, D. Crosby, C. Erickson, B. Harleton, M. Marsiglia, G. Pattison, and C. Stienstra
Presenter First (PF) is a technique for organizing source code and development activities to produce fully tested GUI applications from customer stories using test-driven development. The three elements of Presenter First are a strategy for how applications are developed and tested, a variant on the Model View Presenter (MVP) design pattern, and a particular means of composing MVP triads. Presenter tests provide an economical alternative to automated GUI system tests. We have used Presenter First on projects ranging in size from several to a hundred MVP triads. This paper describes MVP creation, composition, scaling, and the tools and process we use. An example C# application illustrates the application of the Presenter First technique.
Effective Test Driven Development for Embedded Software
IEEE 2006 Electro/Information Technology Conference
Michigan State University, East Lansing, Michigan, USA
Michael Karlesky, William Bereza, and Carl Erickson
Methodologies for effectively managing software development risk and producing quality software are taking hold in the IT industry. However, similar practices for use in embedded systems, particularly in resource constrained systems, have not yet become prevalent. Today, quality in embedded software is generally tied to platform-specific testing tools geared towards debugging. We present here an integrated collection of concrete concepts and practices that are decoupled from platform-specific tools. In fact, this approach drives the actual design of embedded software. These strategies yield good design, systems that are testable under automation, and a significant reduction in software flaws. Examples from an 8 bit system with 16k of program memory and 255 bytes of RAM illustrate these ideas.
Make Haste, not Waste: Automated System Testing
XP Agile Universe
New Orleans, LA, USA
Carl Erickson, Ralph Palmer, David Crosby, Michael Marsiglia, and Micah Alles
When practicing Extreme Programming or other agile development practices, unit testing is a given. But what about system tests? In this paper, which was presented at the XP Universe conference in 2003, the Haste (High-level Automated System Test Environment) approach was introduced. Haste represents an approach to system testing that is philosophically consistent with standard XP unit testing practices. This paper describes the elements of Haste, Atomic Object’s experience with using it to test a complex Java Swing application, and the perspective of the client for whom the application was developed. Haste is available under an open source license.
Copyright © Atomic Object LLC. — Grand Rapids +1 616 776 6020 — Detroit +1 313 444 6010 — Contact Us