book-goos

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.

pg. 69-70

Some concepts from Chapter 14 that need clarification

Idealizing external data

Why is this a good idea?

What's a counter-example: https://gist.github.com/gmccreight/5d2117e0b9a11c52b267

How all the classes work together (and why their separation of responsibilities makes sense)

The adapter that updates what's actually showing in Swing (why do it that way?)

https://github.com/gmccreight/my-goos-code

http://jsfiddle.net/dakra/U3pVM/

book-goos#separation-allows-for-radical-change1 2 "the separation will allow you to make radical changes to the implementation of the code without changing the tests. book-goos#separation-allows-for-radical-change1 2

Ignore (in jMock)

In GOOS chapter 14 they talk about this. Basically, you're saying "yeah yeah, that object can send and receive messages. For this test case I really don't care what it does. It's not what I'm concerned with"

Allow (in jMock)

In GOOS chapter 14 they talk about this. This is used in "Representing Object State by watching its behavior"

Referring Pages