Iniziamo. È gratuito!
o registrati con il tuo indirizzo email
Mock Objects da Mind Map: Mock Objects

1. tools

1.1. per Java

1.1.1. jMock

1.1.1.1. http://www.jmock.org/

1.1.2. EasyMock

1.1.2.1. http://www.easymock.org/

1.1.3. rMock

1.1.3.1. http://rmock.sourceforge.net/

1.1.4. jMockIt

1.1.4.1. https://jmockit.dev.java.net/

1.1.4.2. serve Jdk 1.5

1.2. Elenco tools per altri linguaggi su www.mockobjects.com

2. link utili

2.1. http://www.mockobjects.com/

2.2. "Endo-Testing: Unit Testing with Mock Objects" - XP 2000

2.3. "Mock Roles, not Objects" - OOPLSA 2004

2.4. http://xunitpatterns.com

2.4.1. in particolare la sezione dedicata ai test doubles

2.5. http://del.icio.us/pierodibello/MockObjects

2.6. http://martinfowler.com/articles/mocksArentStubs.html

3. introduzione ai mock

3.1. cosa sono

3.1.1. sono uno strumento di supporto al testing

3.1.1.1. e quindi al TDD

3.1.1.2. in alcuni casi sono uno strumento di design vero e proprio

3.1.1.2.1. interaction-based testing

3.1.1.2.2. jMock

3.1.2. sono delle 'controfigure' di oggetti applicativi

3.1.2.1. da qui il termine Test Double che ora si sta diffondendo per indicare la famiglia di mock, fake, stub, dummy, ...

3.1.2.2. esternamente sono indistinguibili dall'oggetto reale

3.1.2.2.1. offrono le stesse API

3.1.2.3. ma in realta' offrono servizi che consentono di testare meglio gli oggetti che da loro dipendono

3.2. a cosa servono

3.2.1. aiutano a rendere i test piu'

3.2.1.1. isolati e indipendenti

3.2.1.1.1. i test non dipendono dal comportamento dei collaboratori (oggetti secondari)

3.2.1.2. atomici

3.2.1.2.1. i test testano esclusivamente la logica della classe sotto test (oggetto primario)

3.2.1.2.2. non testano anche il corretto comportamento di altri oggetti secondari

3.2.1.3. facili da preparare

3.2.1.3.1. la setUp non deve istanziare i veri collaboratori ma una loro 'controfigura'

3.2.1.4. veloci nell'esecuzione

3.2.1.5. aperti nel design

3.2.1.5.1. per usare i mock si deve per forza 'aprire il design' del proprio codice

4. Chiarire i termini del discorso

4.1. col termine mock objects molte persone indicano tecniche simili ma diverse tra loro

4.1.1. in realta' il termine, strettamente parlando, indica un modo di usare questi oggetti per fare design e per approcciare il TDD

4.1.1.1. Questo modo e' stato definito interaction-based testing (articolo di M.Fowler 'Mocks aren't stubs')

4.2. Test Double

4.2.1. Fake

4.2.1.1. actually has working implementation, but usually take some shortcut which makes it not suitable for production

4.2.1.1.1. an InMemoryDatabase is a good example

4.2.2. Stub

4.2.2.1. Provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test

4.2.2.2. Stubs may also record information about calls

4.2.2.2.1. such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'

4.2.3. Mock

4.2.3.1. sono dei Fake con in piu' la capacita' di programmare e testare quali metodi del mock sono chiamati durante il test

4.2.3.2. is pre-programmed with expectations which form a specification of the calls it's expected to receive

4.2.3.3. can throw an exception if it receive a call it doesn't expect and is checked during verification to ensure it got all the calls it were expecting

4.2.4. Dummy

4.2.4.1. Is passed around but never actually used

4.2.4.2. Usually it's just used to fill parameter lists

4.3. Problema

4.3.1. Vogliamo avere test isolati ed indipendenti

4.3.1.1. ovvero test che verificano esclusivamente la logica di quella singola unita' (tipicamente una classe)

4.3.1.1.1. "An essential aspect of unit testing is to test one feature at time; you need to know exactly what you are testing and where any problems are" (Endo-Testing: Unit Testing with Mock Objects)

4.3.1.2. vogliamo certamente verificare la corretta interazione con gli oggetti con i quali il nostro oggetto sotto test collabora per realizzare i suoi servizi

4.3.1.2.1. ma non vogliamo per questo dipendere dal comportamento dei suoi collaboratori

4.3.2. Vogliamo avere test che non si rompono se quella tale risorsa esterna non e' disponibile (es: il db e' giu')

4.3.3. Vogliamo test che siano il piu' veloce possibili

4.3.3.1. per poterli eseguire piu' spesso possibile