'NET

1
.NET Software Testing

• Andrea Saltarello
• Software Architect Managed Designs S.r.l.
• http//blogs.ugidotnet.org/pape

2
Sponsor
3
Parliamo di

• Design/Test/Interaction patterns
• Unit Testing
• Mock Objects
• Visual Studio 2005

4

• If it aint tested, its broken
• (cit. Bruce Eckel)

5
Software Testing 101

• Possiamo dichiarare funzionante il nostro
  software solo se siamo in grado di dimostrarlo
• Il funzionamento si dimostra mediante appositi
  test
• Utilizzare un software non è considerabile una
  pratica di test (AntiPattern TestByReleasing,
  TestingByPokingAround, )

6
Tipologie di test

• Esistono differenti tipologie di test
• Programmer Test/Technology facing (definiti anche
  unit test)
• Customer Test/Business facing (definiti anche
  acceptance test o functional test)
• Stress/Load Test
• Usage Test
• Noi parleremo di Unit Testing

7
Unit Testing 101

• Lo Unit Testing è una tipologia di test
  automatico, basata sulla possibilità di
  sottoporre a test i singoli componenti di un
  sistema per verificarne la capacità di soddisfare
  i requisiti.
• I suddetti test sono definiti unitari, e sono
  programmi batch che utilizzano le nostre classi
  inviando messaggi prefissati in modo da poter
  verificare la risposta della classe stessa

8
(No Transcript)
9
Toolkit di Unit Testing

• Esistono (almeno) 2 affermati toolkit di unit
  testing per .NET, entrambi ispirati alla suite
  xUnit ideata da Kent Beck ed Erich Gamma
• NUnit
• csUnit
• Noi usiamo NUnit

10
NUnit 101

• NUnit è composto da un assembly (contenente il
  framework di unit testing) e da una applicazione
  host in grado di eseguire i test e produrre un
  report. Per realizzare i test
• Creare una class library che conterrà i test
• Definire una classe, e implementare i test sotto
  forma di metodi
• Decorare i metodi di test con lattributo
  TestAttribute
• Decorare la classe che contiene i test con
  lattributo TestFixture
• Eseguire lassembly dei test mediante
  lapplicazione host

11
Unit Testing - Asserzioni

• Pratica comune nello unit testing è avvalersi
  delle asserzioni, ossia della capacità di
  definire delle condizioni che verificano la
  correttezza di funzionamento del codice in esame
• NUnit permette di definire delle asserzioni
  mediante la classe Assert
• Se lasserzione non è soddisfatta, il test
  fallisce

Test public void TestSum() int number
4 Assert.AreEqual(2, (int) Math.Round(number))

12
(No Transcript)
13
NUnit un assembly con gli Attributi

• La libreria contiene differenti attributi, tra i
  quali
• TestFixture
• Test
• SetUp
• TearDown
• ExpectedException
• Ignore

Test ExpectedException(typeof(ArgumentNullExcep
tion)) public void TestSum() int number
int.Parse(null)
14
Houston, abbiamo un problema!

• Il test unitario insiste su uno specifico
  componente
• Un componente interagisce con altri componenti,
  eventualmente residenti su layer differenti
• Il fallimento di un componente esterno può
  provocare il fallimento di un test
• Può essere conveniente isolare il componente
  sottoposto a test

15
Isolare un componente

• Esistono alcuni pattern specifici, ispirati allo
  Special Case
• Stub/Shunt
• Fake Objects
• Mock Objects
• Diamo anche una occhiata ad Inversion of Control
  (a.k.a. Dependency Injection)

16
Stub/Shunt

• The most simple implementation of an interface.
  Tipically, one might implement every method call
  by throwing a runtime exception.

17
Fake Object

• A class with methods that return a fixed value or
  values that can either be hardcoded or set
  programmatically

18
(No Transcript)
19
Mock Objects

• An object which, in addition to implementing the
  interface (like a Stub/Shunt) and returning
  meaningful values (like a Fake), allows for
  verification that the correct calls were made
  upon the object, perhaps in the correct order.

20
Creare Mock Object

• Esistono toolkit free appositi
• DotNetMock
• NMock
• Noi usiamo NMock

21
NMock

• La classe DynamicMock
• usa CodeDom e Reflection per creare dinamicamente
  un Mock Object
• Permette di istruire il Mock mediante metodi
  quali SetupResult e ExpectAndReturn

DynamicMock mockGenerator new
DynamicMock(typeof(RealObjectType)) RealObjectTyp
e mockObject (RealObjectType)
mockGenerator.MockInstance
mockGenerator.SetupResult(MethodName, 42, new
Type) int result mockObject.MethodName()
22
(No Transcript)
23
Fake vs. Mock

• Secondo Ward Cunningham, dovremmo preferire un
  Mock se
• real object has non-deterministic behavior
• real object is difficult to set up
• real object has behavior that is hard to cause
  (e.g., network error) (similar to 1)
• real object is slow
• real object has (or is) a UI
• test needs to query the object, but the queries
  are not available in the real object (e.g., "was
  this callback called?")
• real object acts "normal" most of the time, but
  once a month (or even less often) it does
  something "exceptional". We want UnitTests to
  make sure the rest of the system does the
  RightThing whether or not the object is acting
  "normal" or "exceptional". (Is this the same as
  2 ?)
• real object does not yet exist

24
Ritorno al Futuro Visual Studio 2005

• I Team System di Visual Studio 2005 includono un
  toolkit di unit testing
• Strepitosamente simile a NUnit (Indovinello dove
  lavora oggi James Newkirk, ex project leader di
  NUnit? ?)
• Dotato di funzionalità di code coverage

25
(No Transcript)
26
Riferimenti

• Tools
• NUnit http//www.nunit.org
• csUnit http//www.csunit.org
• NMock http//www.nmock.org
• DotNetMock http//dotnetmock.sourceforge.net
• TestDriven.NET http//www.testdriven.net
• Documentazione
• NUnit vs. Team System
• Mocks Aren't Stubs
• Mock Stub Shunt
• Mock Objects to the Rescue!

27
Links

• http//www.ugidotnet.org
• http//forum.ugidotnet.org
• http//mobile.ugidotnet.org