How to Write 3v1L, Untestable Code Google Testing Blog Tuesday, November 10, 2009 Valtech © 1

Debugging Sucks – Testing Rocks I can’t cover everything Hang this up for your team to review Valtech © 2

Debugging Sucks – Testing Rocks Make Your Own Dependencies Valtech © 3

Debugging Sucks – Testing Rocks Heavy Duty Constructors Valtech © 4

Debugging Sucks – Testing Rocks Depend on Concrete Classes Valtech © 5

Debugging Sucks – Testing Rocks Conditional Slalom Valtech © 6

Debugging Sucks – Testing Rocks Use Statics Use More Statics Valtech © 7

Debugging Sucks – Testing Rocks Use Global Flags Valtech © 8

Debugging Sucks – Testing Rocks Use Singletons Everywhere Valtech © 9

Debugging Sucks – Testing Rocks Be Defensive - They're out to Get Your Code! Valtech © 10

Debugging Sucks – Testing Rocks Use Primitives Wherever Possible Valtech © 11

Debugging Sucks – Testing Rocks Look for Everything You Need Valtech © 12

Debugging Sucks – Testing Rocks Use static initializes Valtech © 13

Debugging Sucks – Testing Rocks Couple functional code directly to the external systems it depends on Valtech © 14

Debugging Sucks – Testing Rocks Side Effects are the Way to Go Valtech © 15

Debugging Sucks – Testing Rocks Create Utility Classes and Functions/Methods Valtech © 16

Debugging Sucks – Testing Rocks Create Managers and Controllers Valtech © 17

Debugging Sucks – Testing Rocks Do Complicated Creation Work in Objects Valtech © 18

Debugging Sucks – Testing Rocks Utils, Utils, Utils! Valtech © 19

Debugging Sucks – Testing Rocks Use "Refactoring" whenever you need to get away with something Valtech © 20