Demian 8839 test driven devlopment mock objects tdd dev session education ppt powerpoint

Demian 8839 test driven devlopment mock objects tdd dev session education ppt powerpoint - Transcript

Test Driven Development and Mock Objects
DevSession July 2006 Chris Donnan

Copyright 2005 Finetix LLC All Rights Reserved

Some Basic Definitions

Copyright 2005 Finetix LLC All Rights Reserved

What is a Unit Test

General Definition A method of testing the correctness of a particular module of source code
Wikipedia

Copyright 2005 Finetix LLC All Rights Reserved

What is a Unit Test

My More Specific Defintion Testing a method in a class you are writing while you are writing that class

Copyright 2005 Finetix LLC All Rights Reserved

More Definitions
Test Fixture Test Class A class with some unit tests in it Test or Test Method a test implemented in a Test Fixture Test Suite A set of test grouped together Test Harness Runner The tool that actually executes the tests

Copyright 2005 Finetix LLC All Rights Reserved

The SUT The CUT and the MUT
SUT The system under test It is short for whatever thing we are testing and is always defined from the perspective of the test When we are writing unit tests the system under test SUT is whatever class or method s we are testing CUT The class under test the class you are typing code in right now MUT The method under test the method in the CUT you are working on testing now

Copyright 2005 Finetix LLC All Rights Reserved

A Unit Test

Copyright 2005 Finetix LLC All Rights Reserved

The anatomy of a Test Method

Copyright 2005 Finetix LLC All Rights Reserved

Writing Unit Tests
1 Write a test Test driven development always begins with writing a test 2 Run all tests and see the new one fail This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code 3 Write some code The next step is to write some code that will pass the test The new code written at this stage will not be perfect and may for example pass the test in an inelegant way That is acceptable as later steps will improve and hone it It is important that the code written is only designed to pass the test no further and therefore untested functionality must be predicted and allowed for at any stage 4 Run the automated tests and see them succeed If all test cases now pass the programmer can be confident that the code meets all the tested requirements This is a good point from which to begin the final step of the cycle 5 Refactor to remove duplication Now the code can be cleaned up as necessary By re running the test cases the developer can be confident that refactoring is not damaging any existing functionality The concept of removing duplication is an important aspect of any software design In this case however it also applies to removing any duplication between the test code and the production

Copyright 2005 Finetix LLC All Rights Reserved

Rinse and Repeat

The cycle is then repeated starting with another new test to push forward the functionality The size of the steps can be as small as the developer likes or get larger if s he feels more confident If the code written to satisfy a test does not do so then the step size may have been too big and maybe the increment should be split into smaller testable steps TAKE MANY MANY SMALL STEPS

Copyright 2005 Finetix LLC All Rights Reserved

Why on earth would we do this
Tests Keep you out of the time hungry debugger Tests Reduce Bugs in New Features Tests Reduce Bugs in Existing Features Tests Reduce the Cost of Change Tests Improve Design Tests Allow Refactoring Tests Constrain Features Tests Defend Against Other Programmers Testing Is Fun Testing Forces You to Slow Down and Think Testing Makes Development Faster Tests Reduce Fear

Copyright 2005 Finetix LLC All Rights Reserved

Types of Testing
Functionality Testing The functionality of the application i e GUI components against the specifications eg if we click submit button the application should display confirmation dialog box Acceptance testing Formal testing conducted to determine whether a system satisfies its acceptance criteria and thus whether the customer should accept the system Regression Testing Testing the application for checking whether the previous features are working properly or not after adding new features to the application Stress Testing The idea of stress testing is to find the breaking point in order to find bugs that will make that break potentially harmful Load Testing This is merely testing at the highest transaction arrival rate in performance testing to see the resource contention database locks etc Black box Testing Focuses on the program s functionality against the specification White box Testing Focuses on the paths of logic

Copyright 2005 Finetix LLC All Rights Reserved

More types of Testing
Unit Testing The most micro scale of testing to test particular functions or code modules Typically done by the programmer and not by testers as it requires detailed knowledge of the internal program design and code Not always easily done unless the application has a well designed architecture with tight code may require developing test driver modules or test harnesses Integration Testing testing of combined parts of an application to determine if they function together correctly The parts can be code modules individual applications client and server applications on a network etc This type of testing is especially relevant to client server and distributed systems Functional Testing Black box type testing geared to functional requirements of an application this type of testing should be done by testers System Testing Black box type testing that is based on overall requirements specifications covers all combined parts of a system Sanity Testing Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort For example if the new software is crashing systems every 5 minutes bogging down systems to a crawl or destroying databases the software may not be in a sane enough condition to warrant further testing in its current state

Copyright 2005 Finetix LLC All Rights Reserved

Still more types of testing
Performance Testing This term is often used interchangeably with stress and load testing Ideally performance testing and any other type of testing is defined in requirements documentation or QA or Test Plans Usability Testing Testing for user friendliness Clearly this is subjective and will depend on the targeted end user or customer User interviews surveys video recording of user sessions and other techniques can be used Programmers and testers are usually not appropriate as usability testers Installation Uninstallation Testing Testing of full partial or upgrade install uninstall processes Security Testing Testing how well the system protects against unauthorized internal or external access willful damage etc may require sophisticated testing techniques Compatability Testing Testing how well software performs in a particular hardware software operating system network etc environment Ad hoc Testing Testing the application in a random manner Alpha Testing Testing of an application when development is nearing completion minor design changes may still be made as a result of such testing Typically done by end users or others not by programmers or testers Beta Testing Testing when development and testing are essentially completed and final bugs and problems need to be found before final release Typically done by end users or others not by programmers or testers

Copyright 2005 Finetix LLC All Rights Reserved

The point

Unit Tests are a very specific type of test They are NOT lots of things Unit tests are the smallest part of testing They work at the lowest level of granularity

Copyright 2005 Finetix LLC All Rights Reserved

So WHAT is a Unit Test
Your job is to do task X implement some feature You are typing a new class say class X You are NOT typing classes M L N You write unit tests to sort out WHAT YOU ARE TYPING NOW Specify what you want your software to do Do this by writing a unit test Then make the software do what your specification looked like

Copyright 2005 Finetix LLC All Rights Reserved

What does it look like

Copyright 2005 Finetix LLC All Rights Reserved

Or in net

Copyright 2005 Finetix LLC All Rights Reserved

The basic tools
Test Harness Runner aka xUnit
JUnit JUnit NUnit NUnit There are others but most people use these

Copyright 2005 Finetix LLC All Rights Reserved

What does a Test Runner Look Like
NUnit

Copyright 2005 Finetix LLC All Rights Reserved

And JUnit
In Eclipse

Copyright 2005 Finetix LLC All Rights Reserved

State vs Interaction Testing
State Based Testing TestFixture public class StateTester Test public void TwoPlusThreeIsFive RunningSum sum new RunningSum int actual sum AddIntegers 2 3 Assert AreEqual 5 actual

Test public void AddSeveralNumbersAndGetTheRunningSum RunningSum sum new RunningSum sum AddInteger 2 sum AddInteger 3 sum AddInteger 5 Assert AreEqual 10 sum Total



Copyright 2005 Finetix LLC All Rights Reserved

Common Results of State Based Testing
The expected outcome is difficult or time consuming to verify in an automated test The known inputs are difficult or time consuming to setup in an automated test Tests that depend on external services can be brittle or just plain slow Measuring the outcome requires checking the state of all a class s dependencies often making the unit tests too coarse and dependent upon the actual implementation details Too many classes have to be involved in the unit test

Teams abandon TDD as a failure when the tests are too difficult to write or just plain laborious Nobody is going to willingly use a technique that is more bang than buck

Copyright 2005 Finetix LLC All Rights Reserved

The importance of Test First
TDD as a design tool Writing your test first makes you think of the software you are writing as a user of that software Encourages One Class One Responsibility

Copyright 2005 Finetix LLC All Rights Reserved

The importance of IoC
Inversion of Control aka DIP Dependency Inversion Prinicipal
A High level modules should not depend on low level modules Both should depend on abstractions B Abstractions should not depend on details Details should depend on abstractions

Copyright 2005 Finetix LLC All Rights Reserved

The importance of the ISP

The importance of programming to an abstraction vs a concretion

Copyright 2005 Finetix LLC All Rights Reserved

Rules of thumb
If you cannot test code change it so you can Test first Only ONE concrete class per test MOCK THE REST

Copyright 2005 Finetix LLC All Rights Reserved

Principals
Minimize Untestable Code No Test Logic in Production Code Verify One Condition per Test Test Concerns Separately Keep Tests Independent Use the Front Door First do not have special test only ways of using a class Communicate Intent tests are great design usage docs Easy to Setup FAST
Copyright 2005 Finetix LLC All Rights Reserved

A better compiler
Compilers work out type safety Unit tests work out logic safety Refactoring is safely possible

Copyright 2005 Finetix LLC All Rights Reserved

Your application is the 2nd User
Your application is the 2nd user of the code The Unit tests are the 1st user of your API Pioneers are the ones with the arrows in their backs Work out the API with the tests s

Copyright 2005 Finetix LLC All Rights Reserved

Mocks and Other Test Doubles

Copyright 2005 Finetix LLC All Rights Reserved

Test Doubles Test
A Test Double is any object or component that we install in place of the real component specifically so that we can run a test Depending on the reason for why we are using it it can behave in one of four basic ways A Dummy Object is a placeholder object that is passed to the SUT as an argument but is never actually used A Test Stub is an object that is used by a test to replace a real component on which the SUT depends so that the test can control the indirect inputs of the SUT This allows the test to force the SUT down paths it might not otherwise exercise A more capable version of a Test Stub the Recording Test Stub can be used to verify the indirect outputs of the SUT by giving the test a way to inspect them after exercising the SUT A Mock Object is an object that is used by a test to replace a real component on which the SUT depends so that the test can verify its indirect outputs A Fake Object is an object that replaces the functionality of the real depended on component with an alternate implementation of the same functionality

Copyright 2005 Finetix LLC All Rights Reserved

MOCKS Some Terms
Mock Object an object that pretend to be another object and allows to set expectations on its interactions with another object Interaction Based Testing you specify certain sequence of interactions between objects initiate an action and then verify that the sequence of interactions happened as you specified it State Based Testing you initiate an action and then check for the expected results return value property created object etc Expectation general name for validation that a particular method call is the expected one Record Replay model a model that allows for recording actions on a mock object and then replaying and verifying them All mocking frameworks uses this model Some NMock TypeMock Net NMock2 uses it implicitly and some EasyMock Net Rhino Mocks uses it explicitly

Copyright 2005 Finetix LLC All Rights Reserved

Why not JMock
Too Stringy Intelli J Eclipse does not like to refactor strings

Copyright 2005 Finetix LLC All Rights Reserved

Why not NMock
Same thing stringy

Copyright 2005 Finetix LLC All Rights Reserved

Mocks to use

Rhino Mocks net
http www ayende com projects rhino mocks aspx

EasyMock java
http www easymock org NOT STRINGY

Copyright 2005 Finetix LLC All Rights Reserved

Some mock principals to follow
Mocking Interfaces and Classes outside Your Code
In general do not mock code you do not own For example do not mock Active Directory or LDAP in stead create your own interface to wrap the interaction with the external API classes Like

Then you can have an AD implementation

Copyright 2005 Finetix LLC All Rights Reserved

How many mocks
How Many Mock Objects in any Given Test
I ve worked with some people before that felt that there should never be more than 1 2 mock objects involved in any single unit test I wouldn t make a hard and fast rule on the limit but anything more than 2 or 3 should probably make you question the design The class being tested may have too many responsibilities or the method might be too large Look for ways to move some of the responsibilities to a new class or method Excessive mock calls can often be a sign of poor encapsulation

Only Mock your Nearest Neighbor
Ideally you only want to mock the dependencies of the class being tested not the dependencies of the dependencies From hurtful experience deviating from this practice will create unit test code that is very tightly coupled to the internal implementation of a class s dependencies

Copyright 2005 Finetix LLC All Rights Reserved

The law of Demeter LoD

Each unit should only use a limited set of other units only units closely related to the current unit Each unit should only talk to its friends Don t talk to strangers Main Motivation Control information overload We can only keep a limited set of items in short term memory

Too many mocks and mocking past your immediate neighbors are due to violating this prinicpal

Copyright 2005 Finetix LLC All Rights Reserved

Law of Demeter

FRIENDS

Copyright 2005 Finetix LLC All Rights Reserved

closely related

Copyright 2005 Finetix LLC All Rights Reserved

Violations Dataflow Diagram
m 1 b B 2 c C foo

A

4 q 3 p P
Copyright 2005 Finetix LLC All Rights Reserved

bar Q

OO Following of LoD
m

foo2 1 b B 2 foo2 4 bar2 bar2 3 p P q Q c C foo

A

bar

Copyright 2005 Finetix LLC All Rights Reserved

Limitations of Mocks
Can only mock interfaces and virtual members generally

Copyright 2005 Finetix LLC All Rights Reserved

Integrations Tests In a Test Harness
Unit tests cover code in a class without touching real dependencies Integration tests touch concrete dependencies Unit tests are fast Integration tests do not need to be Unit tests do not touch databases web services etc Integration tests do Test harnesses are just too handy

Copyright 2005 Finetix LLC All Rights Reserved

Continuous Integration
An automatic build machine Source control Monitoring service that watches source control repository Scripting engine that can create builds and run test Reporting system to report results of build AND tests

Copyright 2005 Finetix LLC All Rights Reserved

CruiseControl

Copyright 2005 Finetix LLC All Rights Reserved

Cruise Control net

Copyright 2005 Finetix LLC All Rights Reserved

Test Coverage
In Intelli J 6

Copyright 2005 Finetix LLC All Rights Reserved

Clover

Copyright 2005 Finetix LLC All Rights Reserved

Clover Class Report

Copyright 2005 Finetix LLC All Rights Reserved

References
1 http xunitpatterns com 2 http testingsoftware blogspot com 2005 07 different types of testing html 3 http codebetter com blogs jeremy miller articles 129544 aspx EasyMock http www easymock org Rhino Mocks http www ayende com projects rhino mocks aspx Clover http www cenqua com clover CruiseControl http cruisecontrol sourceforge net CruiseControl Net http ccnet thoughtworks com

Copyright 2005 Finetix LLC All Rights Reserved

Inversion Of Control
Inversion Of Control Dependency Injection The Hollywood Principal etc

In stead of instantiating concrete class references in your class depend on an abstraction and allow your concrete dependencies to be given to you

Copyright 2005 Finetix LLC All Rights Reserved

Concrete Class Dependency

Copyright 2005 Finetix LLC All Rights Reserved

Allow dependency to be passed in

Copyright 2005 Finetix LLC All Rights Reserved

Without and With Mocks Test Doubles

IoC Enables this

Copyright 2005 Finetix LLC All Rights Reserved

TDD Encourages DRY KISS YAGNI SRP
DRY Don t repeat yourself KISS Keep it simple stupid YAGNI You aren t going to need it SRP Single Responsibility Principle
There should never be more than one reason for a class to change One class one responsibility

IoC Inversion of Control ISP
Copyright 2005 Finetix LLC All Rights Reserved