Presentation about the Chapter 10 the book Growin Object-Oriented Software, Guided by test. The Walking Skeleton

1. Growing Object-Oriented
Software, Guided by Tests
The Walking Skeleton
Julian Mauricio Angel Aguilar
Medellín
2018

2. The Walking Skeleton
A “walking skeleton” is an implementation of the thinnest possible slice of
real functionality that we can automatically build, deploy, and test end-to-
end.
We keep the skeleton’s application functionality so simple that it’s obvious
and uninteresting, leaving us free to concentrate on the infrastructure.

3. Whit walking skeleton We want our test to start from scratch, build a deploy-
able system, deploy it into a production-like environment, and then run the
tests through the deployed system.
We can’t automate the build, deploy, and test cycle without some idea of the
overall structure.
The Walking Skeleton

4. Find that maintaining a public drawing of the structure of the system, for
example on the wall in the team’s work area, helps the team stay oriented
when working on the code.
No tests are perfect, of course, but in practice we’ve found that a substantial
test suite allows us to make major changes safely.
The objective is to help us understand the requirements well enough to
propose and validate a broad- brush system structure.
The Walking Skeleton

5. For most projects, developing the walking skeleton takes a surprising amount
of effort. First, because deciding what to do will flush out all sorts of
questions about the application and its place in the world. Second, because
the automation of building, packaging, and deploying into a production-like
environment will flush out all sorts of technical and organizational questions.
The Walking Skeleton

6. Build the infrastructure to support the way we want to test the system,
instead of writing the tests to fit in with an existing infrastructure.
We can to start by writing a test as if its implementation already exists, and
then filling in whatever is needed to make it work what Abelson and Sussman
call “programming by wishful thinking. Working backwards from the test
helps us focus on what we want the system to do, instead of getting caught
up in the complexity of how we will make it work.
The Walking Skeleton

7. End-to-End Testing
End-to-end testing for event-based systems, such as our Sniper, has to cope
with asynchrony. The tests run in parallel with the application and do not
know pre- cisely when the application is or isn’t ready. This is unlike unit
testing, where a test drives an object directly in the same thread and so can
make direct assertions about its state and behavior.

8. An end-to-end test can’t peek inside the target application, so it must wait to
detect some visible effect, such as a user interface change or an entry in a log.
The usual technique is to poll for the effect and fail if it doesn’t happen within
a given time limit.
End-to-End Testing

9. An asynchronous test waiting for a value that just flashes on the screen will
be too unreliable for an automated build, so a common technique is to
control the application and step through the scenario. At each stage, the test
waits for an assertion to pass, then sends an event to wake the application for
the next step.
All this makes end-to-end testing slower and more brittle (perhaps the test network is
just busy today), so failures might need interpretation.
End-to-End Testing