SlideShare a Scribd company logo
Testing: 1… 2… 3… An Introduction to DeveloperTesting Will Green will@hotgazpacho.org http://hotgazpacho.org/ @hotgazpacho
Caveat I am Not an Expert http://www.flickr.com/photos/eprater/2375127206/
I am not Kent Beck ,[object Object]
Pioneer of Software Design Patterns
Originator of CRC Cards
One of original signatories of the Agile Manifesto
Author, JUnit (unit testing framework for Java)
Author of several books, including Test Driven Development: By Example
Co-Author: Refactoring: Improving the Design of Existing Codehttp://en.wikipedia.org/wiki/Kent_Beck
I am not Ward Cunningham ,[object Object]
CTO of AboutUs.com
Pioneer of Extreme Programming
Inventor of FIT (Framework for Integrated Tests)http://en.wikipedia.org/wiki/Ward_Cunningham
I am not Martin Fowler ,[object Object]
Co-Author: Refactoring: Improving the Design of Existing Code
Co-Author: Patterns of Enterprise Application Architecture
Author of several other books
One of original signatories of the Agile Manifestohttp://en.wikipedia.org/wiki/Martin_Fowler
I am not Robert C. Martin ,[object Object]
Author, Agile Principles, Patterns, and Practices in C#
Author, Agile Software Development: Principles, Patterns and Practices
Creator of FITNesse(combining FIT with a Wiki)
One of original signatories of the Agile Manifesto
Founder and President of Object Mentor, Inc.http://en.wikipedia.org/wiki/Robert_Cecil_Martin
I amWill Green ,[object Object]
Co-host of The Iron Languages Podcasthttp://ironlanguages.net/
I Read A LOT
I Practice A LOT
I Learn A LOThttp://hotgazpacho.org/
Ready to drink from the fire hose? http://www.flickr.com/photos/joevans/4292116723/
Don’t Think “Test” To-may-to, To-mah-to… http://www.flickr.com/photos/rhinoneal/2706246863/sizes/m/
http://twitter.com/ampgt/status/21689847806 Testing as Design
Testing as Design http://twitter.com/jbogard/statuses/19838298235
Testing as Design http://twitter.com/venkat_s/status/24480762059
Tests aren’t Tests “Test” doesn’t describe what is going on Tests are specification Tests are design Test suites are an artifact of the design process
TDD: Test Driven Design Write the code you wish you had Hard to test == Hard to use Better to find this out now than 2 months from now when you have to change it Done right, helps you adhere to the Principles of Object Oriented Design
SOLID Like a Rock http://www.flickr.com/photos/gustty/2908229462/
Dependency Management Dependency Management is  Hard The single greatest influencer of software quality The foundation for creating software that exhibits the qualities we desire
Poorly Managed Dependencies Lead to code that is Hard to change Fragile Not reusable
Well Managed Dependencies Lead to code that is Flexible Robust Reusable
Qualities of Software Undesirable Hard to change Fragile Not reusable Desirable Easy to change Robust Reusable
Dependency Management and SOLID SOLID is The foundational set of principles for managing dependencies Therefor the foundation for creating software that exhibits the qualities we desire
http://www.lostechies.com/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/derickbailey/SOLID_5F00_6EC97F9C.jpg
What is SOLID? Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
http://www.lostechies.com/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/derickbailey/SingleResponsibilityPrinciple2_5F00_71060858.jpg
Single Responsibility Principle A class should have one, and only one, reason to change http://www.objectmentor.com/resources/articles/srp.pdf
http://www.lostechies.com/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/derickbailey/OpenClosedPrinciple2_5F00_2C596E17.jpg
Open Closed Principle You should be able to extend the behavior of a class, without modifying it Classes should be open for extension but closed for modification http://www.objectmentor.com/resources/articles/ocp.pdf
http://www.lostechies.com/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/derickbailey/LiskovSubtitutionPrinciple_5F00_52BB5162.jpg
Liskov Substitution Principle Derived classes must be substitutable for their base classes http://www.objectmentor.com/resources/articles/lsp.pdf
http://www.lostechies.com/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/derickbailey/InterfaceSegregationPrinciple_5F00_60216468.jpg
Interface Segregation Principle Make fine-grained interfaces that are client-specific http://www.objectmentor.com/resources/articles/isp.pdf
http://www.lostechies.com/cfs-filesystemfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/derickbailey/DependencyInversionPrinciple_5F00_0278F9E2.jpg
Dependency Inversion Principle Depend on abstractions, not on specific implementations http://www.objectmentor.com/resources/articles/dip.pdf
Test Driven Design The Path to Success: 3 Simple Rules http://www.flickr.com/photos/stuckincustoms/4070581709/
Rule #1 You are not allowed to write any production code unless it is to make a failing unit test pass.
Rule #2 You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
Rule #3 You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
The Flow of Test Driven Design Write a Test Watch Test Fail Write Code Watch Test Pass Refactor See step 1 http://gamesfromwithin.com/when-is-it-ok-not-to-tdd
TDD Demo! Fibonacci Number Generator Sequence of numbers First two numbers are 0 and 1 Each subsequent number is the sum of the two previous numbers 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …
How To Test http://www.flickr.com/photos/modestchanges/3214701196/
An Example
Test Naming Method being tested Conditions Expected Outcome
Testing Pattern Arrange, Act, Assert Separates what is being tested from the setup and verification steps Makes some Test Smells more obvious Assertions mixed in with “Act” code. Test methods that try to test too much at once
Arrange Arrange all necessary preconditions and inputs
Act Act on the object or method under test
Assert Assert that the expected results have occurred
Things to Remember Triple A Take Small Steps Run tests after every change Tests are Code; maintain them!
Test Doubles http://www.flickr.com/photos/herbstkind/3791698698/
Mock Repository? Mock? Stub? What is this?
Test Doubles Think “stunt double” Replacement for a Production object for testing purposes There are many types of Test Doubles, each with its own purpose
Dummy Objects Passed around but never used Simply to fill parameter lists
Fake Objects Have working implementations Usually just enough for them to work in the context of the specific test However, not suitable for Production E.g. In-Memory Database
Stubs Provide canned answers to SUT Usually don’t respond to anything more than what was programmed for the context of the test
Spies Stubs that record information on how they were called Allows inspection for Assertion Example Email Service that records the messages it was sent (without actually sending them)
Mocks Pre-programmed with expectations Specify how they should be called by the SUT Throws an exception if they receive a call they were not expecting Checked during the Assert to ensure they got all the calls they were expecting
Refactoring You could do that better… http://www.flickr.com/photos/29108968@N06/2852038148/
Why Refactoring? Improve human readability of code Reduce the complexity in order to improve maintainability Create a more expressive internal structure It’s about DESIGN!!
What is Refactoring? Adisciplinedtechnique for restructuring an existing body of code Altering code’s internal structure without changing its external behavior A series of small steps that do very little on their own Risk of change is mitigated by running automated tests after each step
Refactoring is NOT An undisciplined technique Making changes to code that change its external behavior One giant step Done without a safety net of automated tests
You Are Not Refactoring If you are doing any of those things, your are not refactoring. You’re just changing things willy-nilly. http://www.flickr.com/photos/brymo/2807243701/
How NOT to Test Yeah, don’t do that http://www.flickr.com/photos/bobcatnorth/1199505016/
Test Smells Things that make you go “that just ain’t right” Code Smells Test Smells Project Smells Most of what follows is summarized from  xunitpatterns.com/Test%20Smells.html  the book XUnit Test Patterns: Refactoring Test Code
Test Smells – Code Smells Smells that are found while looking at test code Obscure Test Conditional Test Logic Hard-to-Test Code Test Code Duplication Test Logic in Production
Obscure Test There is trouble understanding what behavior a test is verifying too much or too little information in the test method Possible Solutions Keep tests small and focused Do not depend on external resources (files, databases, web services, etc.)
Conditional Test Logic Hard to know exactly what a test is going to do when it really matters conditional logic to handle when SUT fails to return valid data Loops to verify contents of collections Conditionals to verify complex objects Possible Solutions Custom Assertion Methods
Hard to Test Code Code is difficult to test Highly Coupled Code Asynchronous Code Untestable Test Code Possible Solutions Reduce coupling by using TDD and adhering to SOLID principles Use Test Doubles to isolate the SUT
Test Code Duplication The same code is repeated many times Cut-and-Paste Code Reuse Reinventing the Wheel Possible Solutions Refactor your test code to create Utility Methods
Test Logic in Production Production code contains logic that should only be exercised during tests Conditional logic “For Tests Only” Test Dependency in Production Test-Specific Equality Possible Solutions Test-specific sub-classes of SUT Manage Test Dependencies Custom Assertions
Test Smells – Behavior Smells Smells that jump out at you while running tests Assertion Roulette Erratic Test Fragile Test Frequent Debugging Manual Intervention Slow Tests
Assertion Roulette Hard to tell which of several assertions in the same test caused the test to fail Test tries to verify too much Assertions with unclear failure messages Possible Solutions One logical assertion per test Include a failure message for the assertion Use a GUI test runner
Erratic Test One or more test pass or fail intermittently Tests depend on each other Resource Leakage / Scarcity Shared state Using different/random values for each test run Possible Solutions Use a fresh fixture for each test Clean up after yourself Use Database sandboxes or a Fake Database
Fragile Test A test fails to compile or run when the SUT is changed in ways that do not affect the part the test is exercising Data Sensitivity Over-specifying behavior Context Sensitivity Possible Solutions Do not depend on a database Encapsulate setup behind Creation Methods Abstract away dependencies (including Time)
Frequent Debugging Manual debugging is required to determine the cause of most test failures Caused by Lack of Defect Localization (missing tests) Infrequent Test Runs Possible Solutions Only create behavior after a failing test case Runs tests as part of Continuous Integration builds
Manual Intervention A test requires a person to do some manual action each time it is run, or verify results manually Lack of attention to automated test fixture setup Test is not self-checking Test conditions that are hard to generate programmatically Possible Solutions Invest in automating test setup Use Assertion Methods Use Test stubs to simulate test conditions

More Related Content

What's hot

Improved software testing using Visual Studio and TFS 2010
Improved software testing using Visual Studio and TFS 2010 Improved software testing using Visual Studio and TFS 2010
Improved software testing using Visual Studio and TFS 2010
Alexander Vanwynsberghe
 
Learn How to Unit Test Your Android Application (with Robolectric)
Learn How to Unit Test Your Android Application (with Robolectric)Learn How to Unit Test Your Android Application (with Robolectric)
Learn How to Unit Test Your Android Application (with Robolectric)
Marakana Inc.
 
Unit testing (workshop)
Unit testing (workshop)Unit testing (workshop)
Unit testing (workshop)
Foyzul Karim
 
Android Testing: An Overview
Android Testing: An OverviewAndroid Testing: An Overview
Android Testing: An Overview
SmartLogic
 
Is this how you hate unit testing?
Is this how you hate unit testing?Is this how you hate unit testing?
Is this how you hate unit testing?
Steven Mak
 
Automatic testing in DevOps
Automatic testing in DevOpsAutomatic testing in DevOps
Automatic testing in DevOps
Benoit Baudry
 
R&D on PVS-Studio
R&D on PVS-StudioR&D on PVS-Studio
R&D on PVS-Studio
PVS-Studio
 
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
Mehdi Khalili
 
How To Use Selenium Successfully
How To Use Selenium SuccessfullyHow To Use Selenium Successfully
How To Use Selenium Successfully
Dave Haeffner
 
Unit Testing Your Application
Unit Testing Your ApplicationUnit Testing Your Application
Unit Testing Your Application
Paladin Web Services
 
Integration and Unit Testing in Java using Test Doubles like mocks and stubs
Integration and Unit Testing in Java using Test Doubles like mocks and stubsIntegration and Unit Testing in Java using Test Doubles like mocks and stubs
Integration and Unit Testing in Java using Test Doubles like mocks and stubs
Rody Middelkoop
 
Practical Test Automation Deep Dive
Practical Test Automation Deep DivePractical Test Automation Deep Dive
Practical Test Automation Deep Dive
Alan Richardson
 
Unit Testing 101
Unit Testing 101Unit Testing 101
Unit Testing 101
Dave Bouwman
 
How ANDROID TESTING changed how we think about Death - Second Edition
How ANDROID TESTING changed how we think about Death - Second EditionHow ANDROID TESTING changed how we think about Death - Second Edition
How ANDROID TESTING changed how we think about Death - Second Edition
penanochizzo
 
If you want to automate, you learn to code
If you want to automate, you learn to codeIf you want to automate, you learn to code
If you want to automate, you learn to code
Alan Richardson
 
Codeception introduction and use in Yii
Codeception introduction and use in YiiCodeception introduction and use in Yii
Codeception introduction and use in Yii
IlPeach
 
Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...
Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...
Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...
Alan Richardson
 
[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...
[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...
[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...
Applitools
 
Automating Pragmatically - Testival 20190604
Automating Pragmatically - Testival 20190604Automating Pragmatically - Testival 20190604
Automating Pragmatically - Testival 20190604
Alan Richardson
 
Selenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Selenium Tips & Tricks, presented at the Tel Aviv Selenium MeetupSelenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Selenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Dave Haeffner
 

What's hot (20)

Improved software testing using Visual Studio and TFS 2010
Improved software testing using Visual Studio and TFS 2010 Improved software testing using Visual Studio and TFS 2010
Improved software testing using Visual Studio and TFS 2010
 
Learn How to Unit Test Your Android Application (with Robolectric)
Learn How to Unit Test Your Android Application (with Robolectric)Learn How to Unit Test Your Android Application (with Robolectric)
Learn How to Unit Test Your Android Application (with Robolectric)
 
Unit testing (workshop)
Unit testing (workshop)Unit testing (workshop)
Unit testing (workshop)
 
Android Testing: An Overview
Android Testing: An OverviewAndroid Testing: An Overview
Android Testing: An Overview
 
Is this how you hate unit testing?
Is this how you hate unit testing?Is this how you hate unit testing?
Is this how you hate unit testing?
 
Automatic testing in DevOps
Automatic testing in DevOpsAutomatic testing in DevOps
Automatic testing in DevOps
 
R&D on PVS-Studio
R&D on PVS-StudioR&D on PVS-Studio
R&D on PVS-Studio
 
Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)Automated UI Testing Done Right (QMSDNUG)
Automated UI Testing Done Right (QMSDNUG)
 
How To Use Selenium Successfully
How To Use Selenium SuccessfullyHow To Use Selenium Successfully
How To Use Selenium Successfully
 
Unit Testing Your Application
Unit Testing Your ApplicationUnit Testing Your Application
Unit Testing Your Application
 
Integration and Unit Testing in Java using Test Doubles like mocks and stubs
Integration and Unit Testing in Java using Test Doubles like mocks and stubsIntegration and Unit Testing in Java using Test Doubles like mocks and stubs
Integration and Unit Testing in Java using Test Doubles like mocks and stubs
 
Practical Test Automation Deep Dive
Practical Test Automation Deep DivePractical Test Automation Deep Dive
Practical Test Automation Deep Dive
 
Unit Testing 101
Unit Testing 101Unit Testing 101
Unit Testing 101
 
How ANDROID TESTING changed how we think about Death - Second Edition
How ANDROID TESTING changed how we think about Death - Second EditionHow ANDROID TESTING changed how we think about Death - Second Edition
How ANDROID TESTING changed how we think about Death - Second Edition
 
If you want to automate, you learn to code
If you want to automate, you learn to codeIf you want to automate, you learn to code
If you want to automate, you learn to code
 
Codeception introduction and use in Yii
Codeception introduction and use in YiiCodeception introduction and use in Yii
Codeception introduction and use in Yii
 
Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...
Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...
Risk Mitigation Using Exploratory and Technical Testing - QASymphony Webinar ...
 
[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...
[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...
[Webinar] Continuous Testing Done Right: Test Automation at the World's Leadi...
 
Automating Pragmatically - Testival 20190604
Automating Pragmatically - Testival 20190604Automating Pragmatically - Testival 20190604
Automating Pragmatically - Testival 20190604
 
Selenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Selenium Tips & Tricks, presented at the Tel Aviv Selenium MeetupSelenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
Selenium Tips & Tricks, presented at the Tel Aviv Selenium Meetup
 

Similar to An Introduction to Developer Testing

How do you tame a big ball of mud? One test at a time.
How do you tame a big ball of mud? One test at a time.How do you tame a big ball of mud? One test at a time.
How do you tame a big ball of mud? One test at a time.
Matt Eland
 
Agile Testing Pasadena JUG Aug2009
Agile Testing Pasadena JUG Aug2009Agile Testing Pasadena JUG Aug2009
Agile Testing Pasadena JUG Aug2009
Grig Gheorghiu
 
Getting Started with Test-Driven Development at Longhorn PHP 2023
Getting Started with Test-Driven Development at Longhorn PHP 2023Getting Started with Test-Driven Development at Longhorn PHP 2023
Getting Started with Test-Driven Development at Longhorn PHP 2023
Scott Keck-Warren
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
Sergey Aganezov
 
Quality Built In @ Spotify
Quality Built In @ SpotifyQuality Built In @ Spotify
Quality Built In @ Spotify
Andrii Dzynia
 
TDD Workshop UTN 2012
TDD Workshop UTN 2012TDD Workshop UTN 2012
TDD Workshop UTN 2012
Facundo Farias
 
Testing In Java
Testing In JavaTesting In Java
Testing In Java
David Noble
 
Why test with flex unit
Why test with flex unitWhy test with flex unit
Why test with flex unit
michael.labriola
 
Testing in a glance
Testing in a glanceTesting in a glance
Testing in a glance
Rajesh Kumar
 
So You Just Inherited a $Legacy Application… NomadPHP July 2016
So You Just Inherited a $Legacy Application… NomadPHP July 2016So You Just Inherited a $Legacy Application… NomadPHP July 2016
So You Just Inherited a $Legacy Application… NomadPHP July 2016
Joe Ferguson
 
Specification by example and agile acceptance testing
Specification by example and agile acceptance testingSpecification by example and agile acceptance testing
Specification by example and agile acceptance testing
gojkoadzic
 
Unit Testing, TDD and the Walking Skeleton
Unit Testing, TDD and the Walking SkeletonUnit Testing, TDD and the Walking Skeleton
Unit Testing, TDD and the Walking Skeleton
Seb Rose
 
Types of testing
Types of testingTypes of testing
Types of testing
Sonam Agarwal
 
So You Just Inherited a $Legacy Application...
So You Just Inherited a $Legacy Application...So You Just Inherited a $Legacy Application...
So You Just Inherited a $Legacy Application...
Joe Ferguson
 
BDD with SpecFlow and Selenium
BDD with SpecFlow and SeleniumBDD with SpecFlow and Selenium
BDD with SpecFlow and Selenium
Liraz Shay
 
Code Review
Code ReviewCode Review
Code Review
Ravi Raj
 
10 Ways To Improve Your Code( Neal Ford)
10  Ways To  Improve  Your  Code( Neal  Ford)10  Ways To  Improve  Your  Code( Neal  Ford)
10 Ways To Improve Your Code( Neal Ford)
guestebde
 
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd   seven years afterIan Cooper webinar for DDD Iran: Kent beck style tdd   seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Iranian Domain-Driven Design Community
 
Building Maintainable Android Apps (DroidCon NYC 2014)
Building Maintainable Android Apps (DroidCon NYC 2014)Building Maintainable Android Apps (DroidCon NYC 2014)
Building Maintainable Android Apps (DroidCon NYC 2014)
Kevin Schultz
 
5-Ways-to-Revolutionize-Your-Software-Testing
5-Ways-to-Revolutionize-Your-Software-Testing5-Ways-to-Revolutionize-Your-Software-Testing
5-Ways-to-Revolutionize-Your-Software-Testing
Mary Clemons
 

Similar to An Introduction to Developer Testing (20)

How do you tame a big ball of mud? One test at a time.
How do you tame a big ball of mud? One test at a time.How do you tame a big ball of mud? One test at a time.
How do you tame a big ball of mud? One test at a time.
 
Agile Testing Pasadena JUG Aug2009
Agile Testing Pasadena JUG Aug2009Agile Testing Pasadena JUG Aug2009
Agile Testing Pasadena JUG Aug2009
 
Getting Started with Test-Driven Development at Longhorn PHP 2023
Getting Started with Test-Driven Development at Longhorn PHP 2023Getting Started with Test-Driven Development at Longhorn PHP 2023
Getting Started with Test-Driven Development at Longhorn PHP 2023
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Quality Built In @ Spotify
Quality Built In @ SpotifyQuality Built In @ Spotify
Quality Built In @ Spotify
 
TDD Workshop UTN 2012
TDD Workshop UTN 2012TDD Workshop UTN 2012
TDD Workshop UTN 2012
 
Testing In Java
Testing In JavaTesting In Java
Testing In Java
 
Why test with flex unit
Why test with flex unitWhy test with flex unit
Why test with flex unit
 
Testing in a glance
Testing in a glanceTesting in a glance
Testing in a glance
 
So You Just Inherited a $Legacy Application… NomadPHP July 2016
So You Just Inherited a $Legacy Application… NomadPHP July 2016So You Just Inherited a $Legacy Application… NomadPHP July 2016
So You Just Inherited a $Legacy Application… NomadPHP July 2016
 
Specification by example and agile acceptance testing
Specification by example and agile acceptance testingSpecification by example and agile acceptance testing
Specification by example and agile acceptance testing
 
Unit Testing, TDD and the Walking Skeleton
Unit Testing, TDD and the Walking SkeletonUnit Testing, TDD and the Walking Skeleton
Unit Testing, TDD and the Walking Skeleton
 
Types of testing
Types of testingTypes of testing
Types of testing
 
So You Just Inherited a $Legacy Application...
So You Just Inherited a $Legacy Application...So You Just Inherited a $Legacy Application...
So You Just Inherited a $Legacy Application...
 
BDD with SpecFlow and Selenium
BDD with SpecFlow and SeleniumBDD with SpecFlow and Selenium
BDD with SpecFlow and Selenium
 
Code Review
Code ReviewCode Review
Code Review
 
10 Ways To Improve Your Code( Neal Ford)
10  Ways To  Improve  Your  Code( Neal  Ford)10  Ways To  Improve  Your  Code( Neal  Ford)
10 Ways To Improve Your Code( Neal Ford)
 
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd   seven years afterIan Cooper webinar for DDD Iran: Kent beck style tdd   seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
 
Building Maintainable Android Apps (DroidCon NYC 2014)
Building Maintainable Android Apps (DroidCon NYC 2014)Building Maintainable Android Apps (DroidCon NYC 2014)
Building Maintainable Android Apps (DroidCon NYC 2014)
 
5-Ways-to-Revolutionize-Your-Software-Testing
5-Ways-to-Revolutionize-Your-Software-Testing5-Ways-to-Revolutionize-Your-Software-Testing
5-Ways-to-Revolutionize-Your-Software-Testing
 

Recently uploaded

Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
ssuserfac0301
 
Public CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptxPublic CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptx
marufrahmanstratejm
 
HCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAUHCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAU
panagenda
 
Azure API Management to expose backend services securely
Azure API Management to expose backend services securelyAzure API Management to expose backend services securely
Azure API Management to expose backend services securely
Dinusha Kumarasiri
 
WeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation TechniquesWeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation Techniques
Postman
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
innovationoecd
 
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...
alexjohnson7307
 
Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
Antonios Katsarakis
 
TrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy Survey
TrustArc
 
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3
FREE A4 Cyber Security Awareness  Posters-Social Engineering part 3FREE A4 Cyber Security Awareness  Posters-Social Engineering part 3
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3
Data Hops
 
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing InstancesEnergy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Alpen-Adria-Universität
 
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
Zilliz
 
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Tatiana Kojar
 
Trusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process MiningTrusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process Mining
LucaBarbaro3
 
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUHCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
panagenda
 
Digital Banking in the Cloud: How Citizens Bank Unlocked Their Mainframe
Digital Banking in the Cloud: How Citizens Bank Unlocked Their MainframeDigital Banking in the Cloud: How Citizens Bank Unlocked Their Mainframe
Digital Banking in the Cloud: How Citizens Bank Unlocked Their Mainframe
Precisely
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
Jason Packer
 
SAP S/4 HANA sourcing and procurement to Public cloud
SAP S/4 HANA sourcing and procurement to Public cloudSAP S/4 HANA sourcing and procurement to Public cloud
SAP S/4 HANA sourcing and procurement to Public cloud
maazsz111
 
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
saastr
 
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-EfficiencyFreshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
ScyllaDB
 

Recently uploaded (20)

Taking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdfTaking AI to the Next Level in Manufacturing.pdf
Taking AI to the Next Level in Manufacturing.pdf
 
Public CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptxPublic CyberSecurity Awareness Presentation 2024.pptx
Public CyberSecurity Awareness Presentation 2024.pptx
 
HCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAUHCL Notes and Domino License Cost Reduction in the World of DLAU
HCL Notes and Domino License Cost Reduction in the World of DLAU
 
Azure API Management to expose backend services securely
Azure API Management to expose backend services securelyAzure API Management to expose backend services securely
Azure API Management to expose backend services securely
 
WeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation TechniquesWeTestAthens: Postman's AI & Automation Techniques
WeTestAthens: Postman's AI & Automation Techniques
 
Presentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of GermanyPresentation of the OECD Artificial Intelligence Review of Germany
Presentation of the OECD Artificial Intelligence Review of Germany
 
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...
leewayhertz.com-AI in predictive maintenance Use cases technologies benefits ...
 
Dandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity serverDandelion Hashtable: beyond billion requests per second on a commodity server
Dandelion Hashtable: beyond billion requests per second on a commodity server
 
TrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc Webinar - 2024 Global Privacy Survey
TrustArc Webinar - 2024 Global Privacy Survey
 
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3
FREE A4 Cyber Security Awareness  Posters-Social Engineering part 3FREE A4 Cyber Security Awareness  Posters-Social Engineering part 3
FREE A4 Cyber Security Awareness Posters-Social Engineering part 3
 
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing InstancesEnergy Efficient Video Encoding for Cloud and Edge Computing Instances
Energy Efficient Video Encoding for Cloud and Edge Computing Instances
 
Programming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup SlidesProgramming Foundation Models with DSPy - Meetup Slides
Programming Foundation Models with DSPy - Meetup Slides
 
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
Skybuffer AI: Advanced Conversational and Generative AI Solution on SAP Busin...
 
Trusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process MiningTrusted Execution Environment for Decentralized Process Mining
Trusted Execution Environment for Decentralized Process Mining
 
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUHCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAU
 
Digital Banking in the Cloud: How Citizens Bank Unlocked Their Mainframe
Digital Banking in the Cloud: How Citizens Bank Unlocked Their MainframeDigital Banking in the Cloud: How Citizens Bank Unlocked Their Mainframe
Digital Banking in the Cloud: How Citizens Bank Unlocked Their Mainframe
 
Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024Columbus Data & Analytics Wednesdays - June 2024
Columbus Data & Analytics Wednesdays - June 2024
 
SAP S/4 HANA sourcing and procurement to Public cloud
SAP S/4 HANA sourcing and procurement to Public cloudSAP S/4 HANA sourcing and procurement to Public cloud
SAP S/4 HANA sourcing and procurement to Public cloud
 
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
Deep Dive: AI-Powered Marketing to Get More Leads and Customers with HyperGro...
 
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-EfficiencyFreshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
Freshworks Rethinks NoSQL for Rapid Scaling & Cost-Efficiency
 

An Introduction to Developer Testing

  • 1. Testing: 1… 2… 3… An Introduction to DeveloperTesting Will Green will@hotgazpacho.org http://hotgazpacho.org/ @hotgazpacho
  • 2. Caveat I am Not an Expert http://www.flickr.com/photos/eprater/2375127206/
  • 3.
  • 4. Pioneer of Software Design Patterns
  • 6. One of original signatories of the Agile Manifesto
  • 7. Author, JUnit (unit testing framework for Java)
  • 8. Author of several books, including Test Driven Development: By Example
  • 9. Co-Author: Refactoring: Improving the Design of Existing Codehttp://en.wikipedia.org/wiki/Kent_Beck
  • 10.
  • 12. Pioneer of Extreme Programming
  • 13. Inventor of FIT (Framework for Integrated Tests)http://en.wikipedia.org/wiki/Ward_Cunningham
  • 14.
  • 15. Co-Author: Refactoring: Improving the Design of Existing Code
  • 16. Co-Author: Patterns of Enterprise Application Architecture
  • 17. Author of several other books
  • 18. One of original signatories of the Agile Manifestohttp://en.wikipedia.org/wiki/Martin_Fowler
  • 19.
  • 20. Author, Agile Principles, Patterns, and Practices in C#
  • 21. Author, Agile Software Development: Principles, Patterns and Practices
  • 22. Creator of FITNesse(combining FIT with a Wiki)
  • 23. One of original signatories of the Agile Manifesto
  • 24. Founder and President of Object Mentor, Inc.http://en.wikipedia.org/wiki/Robert_Cecil_Martin
  • 25.
  • 26. Co-host of The Iron Languages Podcasthttp://ironlanguages.net/
  • 27. I Read A LOT
  • 29. I Learn A LOThttp://hotgazpacho.org/
  • 30. Ready to drink from the fire hose? http://www.flickr.com/photos/joevans/4292116723/
  • 31. Don’t Think “Test” To-may-to, To-mah-to… http://www.flickr.com/photos/rhinoneal/2706246863/sizes/m/
  • 33. Testing as Design http://twitter.com/jbogard/statuses/19838298235
  • 34. Testing as Design http://twitter.com/venkat_s/status/24480762059
  • 35. Tests aren’t Tests “Test” doesn’t describe what is going on Tests are specification Tests are design Test suites are an artifact of the design process
  • 36. TDD: Test Driven Design Write the code you wish you had Hard to test == Hard to use Better to find this out now than 2 months from now when you have to change it Done right, helps you adhere to the Principles of Object Oriented Design
  • 37. SOLID Like a Rock http://www.flickr.com/photos/gustty/2908229462/
  • 38. Dependency Management Dependency Management is Hard The single greatest influencer of software quality The foundation for creating software that exhibits the qualities we desire
  • 39. Poorly Managed Dependencies Lead to code that is Hard to change Fragile Not reusable
  • 40. Well Managed Dependencies Lead to code that is Flexible Robust Reusable
  • 41. Qualities of Software Undesirable Hard to change Fragile Not reusable Desirable Easy to change Robust Reusable
  • 42. Dependency Management and SOLID SOLID is The foundational set of principles for managing dependencies Therefor the foundation for creating software that exhibits the qualities we desire
  • 44. What is SOLID? Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  • 46. Single Responsibility Principle A class should have one, and only one, reason to change http://www.objectmentor.com/resources/articles/srp.pdf
  • 48. Open Closed Principle You should be able to extend the behavior of a class, without modifying it Classes should be open for extension but closed for modification http://www.objectmentor.com/resources/articles/ocp.pdf
  • 50. Liskov Substitution Principle Derived classes must be substitutable for their base classes http://www.objectmentor.com/resources/articles/lsp.pdf
  • 52. Interface Segregation Principle Make fine-grained interfaces that are client-specific http://www.objectmentor.com/resources/articles/isp.pdf
  • 54. Dependency Inversion Principle Depend on abstractions, not on specific implementations http://www.objectmentor.com/resources/articles/dip.pdf
  • 55. Test Driven Design The Path to Success: 3 Simple Rules http://www.flickr.com/photos/stuckincustoms/4070581709/
  • 56. Rule #1 You are not allowed to write any production code unless it is to make a failing unit test pass.
  • 57. Rule #2 You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • 58. Rule #3 You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
  • 59. The Flow of Test Driven Design Write a Test Watch Test Fail Write Code Watch Test Pass Refactor See step 1 http://gamesfromwithin.com/when-is-it-ok-not-to-tdd
  • 60. TDD Demo! Fibonacci Number Generator Sequence of numbers First two numbers are 0 and 1 Each subsequent number is the sum of the two previous numbers 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …
  • 61. How To Test http://www.flickr.com/photos/modestchanges/3214701196/
  • 63. Test Naming Method being tested Conditions Expected Outcome
  • 64. Testing Pattern Arrange, Act, Assert Separates what is being tested from the setup and verification steps Makes some Test Smells more obvious Assertions mixed in with “Act” code. Test methods that try to test too much at once
  • 65. Arrange Arrange all necessary preconditions and inputs
  • 66. Act Act on the object or method under test
  • 67. Assert Assert that the expected results have occurred
  • 68. Things to Remember Triple A Take Small Steps Run tests after every change Tests are Code; maintain them!
  • 70. Mock Repository? Mock? Stub? What is this?
  • 71. Test Doubles Think “stunt double” Replacement for a Production object for testing purposes There are many types of Test Doubles, each with its own purpose
  • 72. Dummy Objects Passed around but never used Simply to fill parameter lists
  • 73. Fake Objects Have working implementations Usually just enough for them to work in the context of the specific test However, not suitable for Production E.g. In-Memory Database
  • 74. Stubs Provide canned answers to SUT Usually don’t respond to anything more than what was programmed for the context of the test
  • 75. Spies Stubs that record information on how they were called Allows inspection for Assertion Example Email Service that records the messages it was sent (without actually sending them)
  • 76. Mocks Pre-programmed with expectations Specify how they should be called by the SUT Throws an exception if they receive a call they were not expecting Checked during the Assert to ensure they got all the calls they were expecting
  • 77. Refactoring You could do that better… http://www.flickr.com/photos/29108968@N06/2852038148/
  • 78. Why Refactoring? Improve human readability of code Reduce the complexity in order to improve maintainability Create a more expressive internal structure It’s about DESIGN!!
  • 79. What is Refactoring? Adisciplinedtechnique for restructuring an existing body of code Altering code’s internal structure without changing its external behavior A series of small steps that do very little on their own Risk of change is mitigated by running automated tests after each step
  • 80. Refactoring is NOT An undisciplined technique Making changes to code that change its external behavior One giant step Done without a safety net of automated tests
  • 81. You Are Not Refactoring If you are doing any of those things, your are not refactoring. You’re just changing things willy-nilly. http://www.flickr.com/photos/brymo/2807243701/
  • 82. How NOT to Test Yeah, don’t do that http://www.flickr.com/photos/bobcatnorth/1199505016/
  • 83. Test Smells Things that make you go “that just ain’t right” Code Smells Test Smells Project Smells Most of what follows is summarized from xunitpatterns.com/Test%20Smells.html the book XUnit Test Patterns: Refactoring Test Code
  • 84. Test Smells – Code Smells Smells that are found while looking at test code Obscure Test Conditional Test Logic Hard-to-Test Code Test Code Duplication Test Logic in Production
  • 85. Obscure Test There is trouble understanding what behavior a test is verifying too much or too little information in the test method Possible Solutions Keep tests small and focused Do not depend on external resources (files, databases, web services, etc.)
  • 86. Conditional Test Logic Hard to know exactly what a test is going to do when it really matters conditional logic to handle when SUT fails to return valid data Loops to verify contents of collections Conditionals to verify complex objects Possible Solutions Custom Assertion Methods
  • 87. Hard to Test Code Code is difficult to test Highly Coupled Code Asynchronous Code Untestable Test Code Possible Solutions Reduce coupling by using TDD and adhering to SOLID principles Use Test Doubles to isolate the SUT
  • 88. Test Code Duplication The same code is repeated many times Cut-and-Paste Code Reuse Reinventing the Wheel Possible Solutions Refactor your test code to create Utility Methods
  • 89. Test Logic in Production Production code contains logic that should only be exercised during tests Conditional logic “For Tests Only” Test Dependency in Production Test-Specific Equality Possible Solutions Test-specific sub-classes of SUT Manage Test Dependencies Custom Assertions
  • 90. Test Smells – Behavior Smells Smells that jump out at you while running tests Assertion Roulette Erratic Test Fragile Test Frequent Debugging Manual Intervention Slow Tests
  • 91. Assertion Roulette Hard to tell which of several assertions in the same test caused the test to fail Test tries to verify too much Assertions with unclear failure messages Possible Solutions One logical assertion per test Include a failure message for the assertion Use a GUI test runner
  • 92. Erratic Test One or more test pass or fail intermittently Tests depend on each other Resource Leakage / Scarcity Shared state Using different/random values for each test run Possible Solutions Use a fresh fixture for each test Clean up after yourself Use Database sandboxes or a Fake Database
  • 93. Fragile Test A test fails to compile or run when the SUT is changed in ways that do not affect the part the test is exercising Data Sensitivity Over-specifying behavior Context Sensitivity Possible Solutions Do not depend on a database Encapsulate setup behind Creation Methods Abstract away dependencies (including Time)
  • 94. Frequent Debugging Manual debugging is required to determine the cause of most test failures Caused by Lack of Defect Localization (missing tests) Infrequent Test Runs Possible Solutions Only create behavior after a failing test case Runs tests as part of Continuous Integration builds
  • 95. Manual Intervention A test requires a person to do some manual action each time it is run, or verify results manually Lack of attention to automated test fixture setup Test is not self-checking Test conditions that are hard to generate programmatically Possible Solutions Invest in automating test setup Use Assertion Methods Use Test stubs to simulate test conditions
  • 96. Slow Tests Tests take a long time to run Interaction with external resources (Databases, File Systems, Web Services) Heavy Test fixture rebuilds for every test Asynchronous Test / Explicit delays in the test Too many tests Possible Solutions Abstract away database, file system, web services Use an immutable shared fixture Separate event from the behavior it executes Run a fast subset more, and the entire suite less
  • 97. Test Smells – Project Smells Smells that a project manager can watch out for Buggy Tests Developers Not Writing Tests High Test Maintenance Cost Production Bugs
  • 98. Buggy Tests Bugs are regularly found in automated tests Fragile Tests Obscure Tests Hard to Test Code Possible Solutions Learn to write tests properly Refactor legacy code to make testing easier & more robust Use TDD
  • 99. Developers Not Writing Tests The Usual Excuses Not Enough Time Hard to Test Code Wrong Test Automation Strategy Possible Solutions Learn & Practice writing tests takes less time as you become more familiar with doing it
  • 100. High Test Maintenance Cost Too much time is spent maintaining tests Fragile Tests Obscure Tests Hard to Test code Possible Solutions Learning good Test Automation Practicing TDD
  • 101. Production Bugs Too many bugs found during formal test or in production Infrequently Run Tests Untested Code Missing Unit Tests Lost Tests Possible Solutions Speed up test suite Use TDD Write tests to cover untested code Ensure all tests are part of some suite that is run regularly
  • 102. .NET Testing Tools http://www.flickr.com/photos/booleansplit/2376359338/
  • 103. Testing Frameworks NUnit, MBUnit, XUnit.net Testing frameworks in the xUnit tradition Assertion Engine with syntactical sugar on top
  • 104. Support Libraries Object Factories NBuilder Test Doubles / Isolation Frameworks Hand-rolled mock objects Rhino Mocks Moq NMock EasyMock.NET Typemock Isolator Telerik Just Mock
  • 105. Test Runners NUnitcommand line NUnit GUI TestDriven.NET & Visual Nunit Addins for Visual Studio JetBrainsReSharper or DevExpressCodeRush Integrates with Visual Studio test status next to the test method in the editor JetBrainsTeamCity Continuous Integration server
  • 106. Test Guidance Pair Programming (Dev and QA) Code Reviews Automated Tools Typemock Test Lint
  • 108. Agile Principles, Patterns, and Practices in C# Robert C. Martin Micah Martin
  • 109. Working Effectively with Legacy Code Michael Feathers
  • 110. Refactoring: Improving the Design of Existing Code Martin Fowler Kent Beck John Brant William Opdyke Don Roberts
  • 111. The Art of Unit Testing with Examples in C# Roy Osherove
  • 112. Growing Object-Oriented Software, Guided by Tests Steve Freeman Nat Pryce
  • 113. Testing ASP.NET Web Applications Jeff McWherter Ben Hall
  • 114. MSDN Magazine Articles June 2008 – Patterns in Practice: The Open Closed Principlehttp://msdn.microsoft.com/en-us/magazine/cc546578.aspx October 2008 – Patterns in Practice: Cohesion and Couplinghttp://msdn.microsoft.com/en-us/magazine/cc947917.aspx December 2008 – Patterns in Practice: Design for Testabilityhttp://msdn.microsoft.com/en-us/magazine/dd263069.aspx September 2007 – Unit Testing: Exploring the Continuum of Test Doubleshttp://msdn.microsoft.com/en-us/magazine/cc163358.aspx
  • 115. Videos TDD with Kent Beckhttp://www.pragprog.com/screencasts/v-kbtdd/test-driven-development Test First and Test Driven conversations with Corey Haines and JB Rainsbergerhttp://programmingtour.blogspot.com/2009/07/test-first-and-test-driven-conversation.html Moving Specificity Towards the Tests with Corey Haines and JB Rainsbergerhttp://programmingtour.blogspot.com/2009/08/moving-specificity-towards-tests-with.html Codemanship’s Videos with Jason Gormanhttp://www.youtube.com/user/parlezuml TekPub Concepts serieshttp://tekpub.com/production/concepts
  • 116. Podcasts Hanselminutes Podcast 145 - SOLID Principles with Uncle Bob - Robert C. Martinhttp://www.hanselminutes.com/default.aspx?showID=163 Hanselminutes Podcast 150 – Uncle Bob Martin: SOLID: This Time With Feelinghttp://www.hanselminutes.com/default.aspx?showID=168 Hanselminutes Podcast 146 – Test Driven Development is Design – The Last Word on TDD with Scott Bellwarehttp://www.hanselminutes.com/default.aspx?showID=164 Hanselminutes Podcast 31 – Test Drivenhttp://www.hanselminutes.com/default.aspx?showID=42 Coding QA Podcast 41 – iPhone TDDhttp://codingqa.com/index.php?post_id=622464 Software Engineering Radio Podcast 155 - Johannes Link & LasseKoskelaon TDDhttp://www.se-radio.net/2010/02/episode-155-johannes-link-lasse-koskela-on-tdd/
  • 117. Web Sites The Principles of Object Oriented Designhttp://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod xUnitTest Patternshttp://xunitpatterns.com/ Object Mentor Bloghttp://blog.objectmentor.com/ Martin Fowler’s Bloghttp://martinfowler.com/bliki/ Roy Osherove’s Bloghttp://weblogs.asp.net/ROsherove/

Editor's Notes

  1. …or that there is an impasse with the tools and you have made a conscious decision on the design
  2. As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.The reason it is important to keep a class focused on a single concern is that it makes the class more robust. Continuing with the foregoing example, if there is a change to the report compilation process, there is greater danger that the printing code will break if it is part of the same class.
  3. When a single change results in a cascade of changes to dependent modules, you have a violation of the Open Closed Principle
  4. A typical example that violates LSP is a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently. Mutability is a key issue here. If Square and Rectangle had only getter methods (i.e. they were immutable objects), then no violation of LSP could occur.
  5. In a nutshell, no client should be forced to depend on methods it does not use.
  6. Fibonacci Sequence Generator