We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Testing with No Harm

Formal Metadata

Title
Testing with No Harm
Title of Series
Number of Parts
133
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
If you’re a programmer, chances are you’ve heard about “Test-induced design damage”. This catchy phrase, coined by Ruby on Rails author David Heinemeier Hansson, implies that the dogmatic practice of Test-driven development can harm the structure of the software it’s meant to protect. Besides its sensationalism, that statement served to take a step back and reason about the practice of writing automated tests. What compromises do we make to gain the confidence of a well-covered code base? Do automated tests inhibit good design? In this session we’ll explore those questions by looking at how writing automated tests affects our design choices. We’ll look at approaches like BDD and Specification by Example and how they use tests as a way to lead the design to fit its purpose. We’ll also look at balancing unit tests with integration and end-to-end tests in order to decouple our tests from the internal structure of the system. All to achieve the honorable goal of writing tests with no harm done.