The Art of Unit Testing

Transcription

1 The Art of Unit Testing with Examplee in.net Roy Oeberove 11 MANNING Greenwich (74 w. long.)

2 Contents foreword t xv preface xvii acknowledgments xix about this book xx about the cover illustration XXIII PART 1 GETTING STARTED 1 1 The basics of unit testing 3 /. / Unit testing the classic definition 4 The importance of writing "good" unit tests all written unit tests (sort of) Properties of a good unit test Integration tests 7 Drawbacks of integration tests compared to automated unit tests 9 /.4 öms/ unit test a definition A simple unit test example Test-driven development Summary 19 5 о We've 2 A first unit test Frameworks for unit testing 22 What unit-testing frameworks offer frameworks о The xunit ix

3 x Contents 2.2 Introducing the Log An project Firet steps with NUnit 26 Installing NUnit 26 о Loading up the solution 26 о Using the NUnit attributes in your code 29 Z-4 Writing our first test 50 The Assert class 31 о Running our first test with NUnit 32 о Fixing our code and passing the test 33 о From red to green More NUnit attributes 54 Setup and teardown 34 о Checking for expected exceptions 36 о Ignoring tests 3S> о Setting test categories 39? Indirect testing of state Summary 44 PART 2 CORE TECHNIQUES 47 3 Using stubs to break dependencies 49 5/ Introducing stubs SO 5.2 Identifying a filesystem dependency in Log An Determining how to easily test LogAnalyzer Refactoring our design to be more testable 55 Extract an interface to allow replacing underlying implementation 55 о Inject stub implementation into a class under test 50 о Receive an interface at the constructor level [constructor injection) 55 о Receive an interface as a property get or set 64 о Getting a stub just before a method call Variations on refactoring techniques 74 Using Extract and Override to create stub results > Overcoming the encapsulation problem 77 Using internal and [InternalsVisibleTo] 70 о Using the [Conditional] attribute 79 о Using #if and #endif with conditional compilation 8>0 5.7 Summary 30

4 Contents 4 Interaction testing using mock objects &2 4.1 State-based versus interaction testing The difference between mocks and stubs A simple manual mock example Using a mock and a stub together One mock per test Stub chains: stubs that produce mocks or other stubs 4.7 The problems with handwritten mocks and stubs Summary 97 5 Isolation (mock object) frameworks Why use isolation frameworks? ЮО 5.2 Dynamically creating a fake object 102 Introducing Rhino Mocks into your tests 102 о Replacing a handwritten mock object with a dynamic one Strict versus nonstrict mock objects 106 Strict тоске Ю6 о Nonstrict mocks Returning values from fake objects ЮЗ 5.5 Creating smart stubs with an isolation framework 110 Creating a stub in Rhino Mocks 110 о Combining dynamic stubs and mocks Parameter constraints for mocks and stubs 115 Checking parameters with string constraints 115 Checking parameter object properties with constraints 11Ö о Executing callbacks for parameter verification Testing for event-related activities 121 Testing thatan event has been subscribed to 122 о Triggering events from mocks and stubs 123 о Testing whether an event was triggered Arrange-act-assert syntax for isolation Currentisolationframeworksfor.NET 130 NUnit.Mocks 130 о NMock 131 о NMock2 131 о Typemock Isolator 132 Rhino Mocks 132 о Moq 134

5 xii Contents 5.Ю Advantages of isolation frameworks Traps to avoid when using isolation frameworks 135 Unreadable test code 135 о Verifying the wrong things 136 о Having more than one mock per test 136 о Overspecifying the tests Summary 137 PART3 THE TE5T CODE Test hierarchies and organization 141 и 7 Having automated builds run automated tests 142 Anatomy of an automated build 142 о Triggering builds and continuous Integration 144 о Automated build types 144?.i? Mapping out tests based on speed and type 145 The human factor of separating unit from Integration tests 146 о The safe green zone Ensuring tests are part of source control Mapping test classes to code under test 143 Mapping tests to projects 145 о Mapping tests to classes 149 Mapping tests to specific methods uilding a test API for your application ' 150 Using test class Inheritance patterns 151 о Creating test utility classes and methods 167 Making your API known to developers Summary The pillars of good tests 171 Z7 Writing trustworthy tests 172 Deciding when to remove or change tests 172 о Avoiding logic in tests 175 о Testing only one thing 179 о Making tests easy to run 1&0 о Assuring code coverage Writing maintainable tests 131 Testing private or protected methods 182 о Removing duplication 184 о Using setup methods In a maintainable manner 188 о Enforcing test isolation 191 о Avoiding multiple asserts 198 о

6 Contents xiii Avoiding testing multiple aspects of the same object 202 о Avoiding overspecification in tests 205 ZJ Writing readable teste 209 Naming unit tests 210 о Naming variables 211 о Asserting yourself with meaning 212 о Separating asserts from actions 214 о Setting up and tearing down 214 Z-4 Summary 215 PART 4 DESIGN AND PROCESS Integrating unit testing into the organization 219 Ä 7 Steps to becoming an agent of change 220 F3e prepared for the tough questions 220 о Convince insiders: champions and blockers 220 о Identify possible entry points 222 Äi? H^j/5 ft? succeed 223 Guerrilla implementation (bottom-up) 223 о Convincing management (top-down) 224 о Getting an outside champion 224 о Making progress visible 225 о Aiming for specific goals 227 о Realizing that there will be hurdles 22Ö 3.3 Ways to fail 229 Lack of a driving force 229 о Lack of political support 229 о 3ad implementations and first impressions 230 о Lack of team support Tough questions and answers 231 How much time will this add to the current process? 231 о Will my QA job be at risk because of this? 233 о How do we know this is actually working? 234 о Is there proof that unit testing helps? 234 о Why is the QA department still finding bugs? 235 о We have lots of code without tests: where do we start? 235 о We work in several languages: is unit testing feasible? 236 о What if we develop a combination of software and hardware? 236 о How can we know we don't have bugs in our tests? 236 о I see In my debugger that my code works fine: why do I need tests? 237 о Must we do TCP-style coding? Summary 233

7 xiv Contents 9 Working with legacy code Where do you start adding tests? Choosing a selection strategy 242 Pros and cons of the easy-first strategy 242 о Pros and cone of the hard-first strategy Writing integration tests before refactoring Important tools for legacy code unit testing 246 Isolate dependencies easily with Typemock Isolator 246 о Find testability problems with Depender 246 Use JMockit for Java legacy code 246 о Use Vise while refactoring your Java code 250 о Use FitNesse for acceptance tests before you refactor 251 о Read Michael Feathers' book on \egacy code 253 о Use NDepend to investigate your production code 253 о Use ReSharperto navigate and refactor production code 253 о Detect duplicate code {and bugs) with Simian 254 о Detect threading issues with Typemock Racer 254 Ä5 Summary 254 Appendix A Design and testability 256 Appendix 3 Extra toole and frameworks 268 Index 264