Join us on:

T38. Robots Wild On Software

Ted Layher, Menlo Innovations, LLC.

Ted is currently a software developer at Menlo Innovations with 5 years experience in agile projects. His professional career started in the middle of the dot com bubble and has survived despite several company's best efforts. Ted career began as a unix systems administrator working for a large automotive corporation and small local companies . He has enjoyed evolving into a software developer. Ted brings an interesting mix of operational, systems knowledge and Test Driven Development skills to the team. He influences the team through excellent coaching skills. Ted has a bachelor's degree in Computer Science from Eastern Michigan University.

Kealy Opelt, Menlo Innovations, LLC.

Kealy Opelt is a Software Developer for Menlo Innovations. She has ten years programming experience including over four years focused work with Extreme Programming(XP) team projects. Working in an XP environment has created a love and commitment to the agile team practices for Kealy. Her commitment made instruction an easy transition at Menlo Innovations teaching their philosophies and practice. Kealy has presented her experience on Agile teams for over a year at a few Mid-West conferences and continues to expose others to XP and agile.

Developers never get to play with the cool toys. Now's your chance! This tutorial explores architectural layering and unit testing strategies for an application that controls a robot. Test-Driven Development teams use mock objects to fake up parts of the code that are not the focus of the test. Mocking the communication layer for the robot facilitates writing stronger unit tests. With this layer in place, it is easy to create a hardware simulation to aid demo's and functional testing. Come get hands on and learn about these techniques using a Lego® Mindstorms® NXT robot and your pair partner.


The Java developer who attends this tutorial will learn one technique for limiting software hooks into the hardware. This will be reinforced by applying this technique in a hands-on exercise, programing a robot (aka hardware). While having fun making the robot come to life each developer will gain experience with pair programming and test-driven development.


Most people think that writing unit tests for a robot is too hard or just plain impossible. We will spend the first part of the session explaining how to create an architectural boundary around the hardware and keep it separate from the rest of the software. Once the boundary has been established we will demonstrate creating mock objects as a substitute hardware layer.

The attendees will be given an API and explanation of its methods which control the robot. Everyone will be asked to pair up and then given the same programming assignment for the robot. The assignment could be something like: run a maze, follow the line, or pick up sticks.

The second half of the session is for writing unit tests and code for the assignment. Each pair can only connect to the robot when they have sufficient unit tests demonstrating their solution, simulating typical hardware development limitations. They will be asked to share their architectural and testing strategies.

Question and Answers will be fielded throughout the session.

Audience: Practitioners
Please email any questions to . This e-mail address is being protected from spambots. You need JavaScript enabled to view it