Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Growin Object-Oriented Software - The Walking Skeleton


Published on

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

Published in: Software
  • Be the first to comment

  • Be the first to like this

Growin Object-Oriented Software - The Walking Skeleton

  1. 1. Growing Object-Oriented Software, Guided by Tests The Walking Skeleton Julian Mauricio Angel Aguilar Medellín 2018
  2. 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. 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. 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. 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. 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. 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. 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. 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