Most of chapter 7  and 8 were things I had already learned from the previous testing class that I had taken. He goes over that unit tests are different than acceptance test, always try to make automated tests because they are cheaper, and all the different types of testing their are and what each one of them covers in the system.
The main thing that I took away from this chapter was that you, as a developer, should make sure that clear communication is established between your team and the stakeholders that you’re working with. Primarily you don’t ever want to assume that the other party knows what you are talking about, or that you are on the same page.  These assumptions can, and usually will, lead to huge messes down the line that may result in your team having to fix the entire design of an application that you were building because you misunderstood critical information that the client was ambiguous on. So, moral of the chapter, never be afraid to ask question and bring in people that may help to clarify the story that the client gives you.
I did also find the small section on testing GUIs interesting. Martin points out that you should not test the GUI itself, but the under lying structure by designing they system to treat it like an API. This makes perfect sense when you think about it because a GUI will always be changing to whatever the clients preference is.