TDD: The Bad Parts — Matt Parker

August 19, 2016
Slides: http://www.slideshare.net/Pivotal/tdd-the-bad-parts TDD, the savior of bad code, the promise of a better world. And yet… so many teams have tried TDD and failed. It’s a deceptively simple practice that actually requires a good deal of craftsmanship and skill to wield effectively. Through explanations and examples, we’ll examine a number of common problems teams face, including: Test Coupling Many folks our community promote the idea that unit testing means having a test file for every production class, and a test for every public method. And yet this tightly couples tests to the underlying design patterns of the codebase, and makes it hard to refactor. We’ll look at a way to minimize the surface area of your testing and intentionally define an interface between your tests and production code. Mocking (Hammer of the Gods) Mockito (and libraries like it) have created very simple and powerful ways for Java developers to create and use test doubles in their tests. And yet those libraries have also led to a good deal of misunderstanding and misuse of test doubles. We’ll examine the five types of test doubles, their roles, and when they’re applicable – and we’ll also look at the common problems developers run into misusing these tools and concepts. Death by a Thousand Flakes Outside-in behavior driven development is a commonly used practice. And yet we have too often conflated “outside” with ”GUI” – with disastrous results. We’ll look at the problems this has caused, including slow test suites, flaky test suites, upside down testing pyramids, and more. Test Suite Bankruptcy When all of these bad practices combine, they lead to one place: test suite bankruptcy. We’ll examine a case study of a team that, with the best intentions, applied all of these practices together for the better part of a year, and was forced to declare test suite bankruptcy at the end. We’ll talk about the tell-tale signs that you are approaching bankruptcy, and what you should do if you ever find yourself in that situation (or inheriting that situation from others). SpringOne Platform 2016 Speaker: Matt Parker; Engineering Director, Pivotal.
Previous
Cloud-Native Security: Rotate, Repair, Repave — Justin Smith
Cloud-Native Security: Rotate, Repair, Repave — Justin Smith

Slides: http://www.slideshare.net/Pivotal/cloud-native-security-rotate-repair-repave Enterprise software s...

Next
Simplifying the Future — Adrian Cockcroft, Battery Ventures
Simplifying the Future — Adrian Cockcroft, Battery Ventures

Slides: http://www.slideshare.net/Pivotal/adrian-cockcroft-simplifying-the-futurec Adrian Cockcroft, Techn...

Subscribe to Pivotal videos on YouTube!

Subscribe