Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Growing Object Oriented Software Guided By Test

A Book Review

James Carr

on 19 May 2010

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Growing Object Oriented Software Guided By Test

A Book Review By James Carr Part I: Introduction Part III: A Worked Example Part V: Advanced Topics Part IV: Sustainable Test-Driven
Development Write a Failing
Acceptance Test Write a Failing
Unit Test Make it pass Start Here Refactor Inner Feedback Loop Inner and Outer
Feedback Loop
In TDD Outer Feedback Loop
Illustrates concepts using a real world example
Examples are here: http://www.growing-object-oriented-software.com/code.html Listen to Your Tests Logging is a Feature Too Many Dependencies Too Many Expectations Write fewer expectations
Maybe even follow the principle of one expecation per test :) Keep knowledge local
If it's explicit, we can name it
More names mean more domain information
Pass behavior rather than data Test Readability Strive fore readability and clear expression of intent
If I have to dig through 30 lines of a test method, it's hard to see the point
Treat test code as if it were living documentation Testing Asynchronous Code Hamcrest Assertions Creating your own custom hamcrest matchers Testing Multi-Threading Part II: The Process Of
Test Driven Development Testing a "Walking Skeleton" Object Oriented Style Object Peer Stereotypes Notifications Dependencies Adjustments Use Interfaces to Define Roles Impl Classes are MEANINGLESS
Look for something in the implementation that makes it specific
Maybe the interface is poorly designed? Avoid "Train Wrecks" Only Mock Types You Own Don't Mock Types You Can't Change Exposes internals to the world
Result: Clients have the behavior to "do the work"
Even worse: Related behavior spread out across the system! ((EditableItem)master.getDockablePanel()
.getSavedItem()).setEnabled(false) Design for Maintainability Separation of Concerns
Higher levels of abstraction
Cockburn's "Ports and Adapters" architecture [Cockburn08] To put it simply, we can get more done by dealing with domain concepts rather than manipulating ints and strings that control flow Start by writing a single end to end test for a thin vertical slice of functionality
Period of discovery
Draws out the context of the project
Context of the First Test Understand
the problem Broad-Brush
Design Automate Build
End-to-End Tests Write a Failing
Acceptance Test Write a Failing
Unit Test Make it pass Refactor Production Release Deployable
System Test Behavior, Not Methods Think about how to use this object to achieve a goal NOT how to exercise all the paths through its code! Value Types Breaking Out Budding Off Bundling Up immutable
have no identity or state Mark a new domain concept that might sit as a placeholder Compose value type from group of values passed around together
Can be volatile until a missing concept is found Questions? Comments?
Debate? :) Thank You! Introduction To JUnit Intro to JMock
Intro to Hamcrest Streamline Assertions Test Diagnostics Make the reason why a test failed explicit
Full transcript