Mais conteúdo relacionado
Semelhante a Tdd dev session (20)
Tdd dev session
- 1. Copyright © 2005 Finetix LLC
All Rights Reserved
Test Driven Development and Mock ObjectsTest Driven Development and Mock Objects
DevSession July 2006
-Chris Donnan-
- 2. Copyright © 2005 Finetix LLC
All Rights Reserved
Some Basic DefinitionsSome Basic Definitions
- 3. Copyright © 2005 Finetix LLC
All Rights Reserved
What is a “Unit Test”What is a “Unit Test”
General Definition:
A method of testing the correctness of a particular module of source
code
-Wikipedia
- 4. Copyright © 2005 Finetix LLC
All Rights Reserved
What is a “Unit Test”What is a “Unit Test”
My More Specific Defintion:
Testing a method in a class you are writing – while you are writing that
class.
- 5. Copyright © 2005 Finetix LLC
All Rights Reserved
More DefinitionsMore 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.
- 6. Copyright © 2005 Finetix LLC
All Rights Reserved
The SUT, The CUT and the MUTThe 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.
- 8. Copyright © 2005 Finetix LLC
All Rights Reserved
The anatomy of a Test MethodThe anatomy of a Test Method
- 9. Copyright © 2005 Finetix LLC
All Rights Reserved
Writing Unit TestsWriting 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 .
- 10. Copyright © 2005 Finetix LLC
All Rights Reserved
Rinse and RepeatRinse 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
- 11. Copyright © 2005 Finetix LLC
All Rights Reserved
Why on earth would we do this?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
- 12. Copyright © 2005 Finetix LLC
All Rights Reserved
Types of TestingTypes 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.
- 13. Copyright © 2005 Finetix LLC
All Rights Reserved
More types of TestingMore 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.
- 14. Copyright © 2005 Finetix LLC
All Rights Reserved
Still more types of testingStill 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.
- 15. Copyright © 2005 Finetix LLC
All Rights Reserved
The point?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.
- 16. Copyright © 2005 Finetix LLC
All Rights Reserved
So WHAT is a Unit Test?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.
- 17. Copyright © 2005 Finetix LLC
All Rights Reserved
What does it look like?What does it look like?
- 19. Copyright © 2005 Finetix LLC
All Rights Reserved
The basic toolsThe basic tools
Test Harness/ Runner – aka – xUnit
– JUnit – JUnit
– NUnit - NUnit
There are others – but – most people use these
- 20. Copyright © 2005 Finetix LLC
All Rights Reserved
What does a Test Runner Look Like?What does a Test Runner Look Like?
NUnit
- 21. Copyright © 2005 Finetix LLC
All Rights Reserved
And JUnitAnd JUnit
In Eclipse
- 22. Copyright © 2005 Finetix LLC
All Rights Reserved
State vs. Interaction TestingState 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);
}
}
- 23. Copyright © 2005 Finetix LLC
All Rights Reserved
Common Results of State Based TestingCommon 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.
- 24. Copyright © 2005 Finetix LLC
All Rights Reserved
The importance of Test FirstThe 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
- 25. Copyright © 2005 Finetix LLC
All Rights Reserved
The importance of IoCThe 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.
- 26. Copyright © 2005 Finetix LLC
All Rights Reserved
The importance of the ISPThe importance of the ISP
The importance of programming to an abstraction vs a concretion
- 27. Copyright © 2005 Finetix LLC
All Rights Reserved
Rules of thumbRules of thumb
If you cannot test code – change it so you can.
Test first!
Only ONE concrete class per test – MOCK THE REST.
- 28. Copyright © 2005 Finetix LLC
All Rights Reserved
PrincipalsPrincipals
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!
- 29. Copyright © 2005 Finetix LLC
All Rights Reserved
A ‘better’ compilerA ‘better’ compiler
Compilers work out type safety
Unit tests work out logic safety
Refactoring is safely possible
- 30. Copyright © 2005 Finetix LLC
All Rights Reserved
Your application is the 2Your application is the 2ndnd
UserUser
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
- 31. Copyright © 2005 Finetix LLC
All Rights Reserved
Mocks and Other Test DoublesMocks and Other Test Doubles
- 32. Copyright © 2005 Finetix LLC
All Rights Reserved
Test DoublesTest Doubles
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.
- 33. Copyright © 2005 Finetix LLC
All Rights Reserved
MOCKS!!!! Some TermsMOCKS!!!! 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.
- 34. Copyright © 2005 Finetix LLC
All Rights Reserved
Why not JMockWhy not JMock
Too Stringy – Intelli-J, Eclipse does not like to refactor strings.
- 35. Copyright © 2005 Finetix LLC
All Rights Reserved
Why not NMockWhy not NMock
Same thing – stringy!!!
- 36. Copyright © 2005 Finetix LLC
All Rights Reserved
Mocks to useMocks to use
Rhino.Mocks (.net)
– http://www.ayende.com/projects/rhino-mocks.aspx
EasyMock (java)
– http://www.easymock.org/
NOT STRINGY!!!
- 37. Copyright © 2005 Finetix LLC
All Rights Reserved
Some mock principals to followSome 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
- 38. Copyright © 2005 Finetix LLC
All Rights Reserved
How many mocks????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.
- 39. Copyright © 2005 Finetix LLC
All Rights Reserved
The law of Demeter (LoD)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.
- 40. Copyright © 2005 Finetix LLC
All Rights Reserved
Law of DemeterLaw of Demeter
FRIENDS
- 41. Copyright © 2005 Finetix LLC
All Rights Reserved
““closely related”closely related”
- 42. Copyright © 2005 Finetix LLC
All Rights Reserved
Violations: Dataflow DiagramViolations: Dataflow Diagram
A
B C
1:b 2:c
P Q
3:p()
4:q()
foo()
bar()
m
- 43. Copyright © 2005 Finetix LLC
All Rights Reserved
OO Following of LoDOO Following of LoD
A
B C
1:b c
P Q
3:p() q()
foo()
bar()
m
2:foo2()
4:bar2()
foo2
bar2
- 44. Copyright © 2005 Finetix LLC
All Rights Reserved
Limitations of MocksLimitations of Mocks
Can only mock interfaces and virtual members (generally)
- 45. Copyright © 2005 Finetix LLC
All Rights Reserved
Integrations Tests In a Test HarnessIntegrations 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
- 46. Copyright © 2005 Finetix LLC
All Rights Reserved
Continuous IntegrationContinuous 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
- 48. Copyright © 2005 Finetix LLC
All Rights Reserved
Cruise Control.netCruise Control.net
- 49. Copyright © 2005 Finetix LLC
All Rights Reserved
Test CoverageTest Coverage
In Intelli-J 6
- 51. Copyright © 2005 Finetix LLC
All Rights Reserved
Clover Class ReportClover Class Report
- 52. Copyright © 2005 Finetix LLC
All Rights Reserved
ReferencesReferences
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/
- 53. Copyright © 2005 Finetix LLC
All Rights Reserved
Inversion Of ControlInversion 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.
- 54. Copyright © 2005 Finetix LLC
All Rights Reserved
Concrete Class DependencyConcrete Class Dependency
- 55. Copyright © 2005 Finetix LLC
All Rights Reserved
Allow dependency to be passed inAllow dependency to be passed in
- 56. Copyright © 2005 Finetix LLC
All Rights Reserved
Without and With Mocks/ Test DoublesWithout and With Mocks/ Test Doubles
IoC Enables this
- 57. Copyright © 2005 Finetix LLC
All Rights Reserved
TDD Encourages DRY, KISS, YAGNI, SRPTDD 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