SimpleTest

Revision: 1956
          http://simpletest.svn.sourceforge.net/simpletest/?rev=1956&view=rev
Author:   arialdomartini
Date:     2009-09-29 14:05:59 +0000 (Tue, 29 Sep 2009)

Log Message:
-----------
Translations from English to Italian: finished!
Now, debug.

Modified Paths:
--------------
    simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml
    simpletest/trunk/docs/source/it/improving_design_tutorial.xml
    simpletest/trunk/docs/source/it/mock_objects_tutorial.xml

Modified: simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml	2009-09-28 14:21:30 UTC (rev 1955)
+++ simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml	2009-09-29 14:05:59 UTC (rev 1956)
@@ -6,81 +6,83 @@
     </long_title>
     <content>
         <introduction>
-            <p>
-                You are probably thinking that we have well and truly exhausted
-                the <code>Log</code> class by now and that there is
-                really nothing more to add.
-                Things are never that simple with object oriented programming, though.
-                You think you understand a problem and then something comes a long
-                that challenges your perspective and leads to an even deeper appreciation.
-                I thought I understood the logging class and that only the first page
-                of the tutorial would use it.
-                After that I would move on to something more complicated.
-                No one is more surprised than me that I still haven&apos;t got to
-                the bottom of it.
-                In fact I think I have only just figured out what a logger does.
+            <p>	
+				Probabilmente starai pensando che abbiamo esaurito ogni argomento
+				a proposito della classe <code>Log</code> e che adesso non c'è
+				davvero niente da aggiungere.
+				Ma le cose non sono mai così semplici nella programmazione orientata agli oggetti.
+				Pensi di aver compreso un problema quando sopraggiunge qualcosa che
+				sfida le tue convinzioni e ti porta ad una comprensione ancora più profonda.
+				Credevo di aver capito la classe log e che l'avrei citata solo nella
+				prima pagina del tutorial per dedicarmi in seguito a qualcosa di più
+				complesso. Nessuno è più sopreso di me nel non riuscire ancora a
+				vederne il fondo.
+				In effetti, penso di aver solo dato una vaga idea di cosa faccia una
+				classe per il logging.
             </p>
         </introduction>
-        <section name="variation" title="Log variations">
+        <section name="variation" title="Gestire le variazioni nel logger.">
             <p>
-                Supposing that we do not want to log to a file at all.
-                Perhaps we want to print to the screen, write the messages to a
-                socket or send them to the Unix(tm) <em>syslog</em> daemon for
-                dispatching across the network.
-                How do we incorporate this variation?
+				Supponiamo che non si voglia affatto fare il log su un file.
+				Forse desideriamo stampare il messaggio sullo schermo o scriverlo
+				su un socket o spedirmo al demone <em>syslog</em> di Unix(tm) perché
+				sia distribuito sulla rete.
+				Come possiamo incorporare queste variazioni?
             </p>
             <p>
-                Simplest is to subclass the <code>Log</code>
-                overriding the <code>message()</code> method
-                with new versions.
-                This will work in the short term, but there is actually something
-                subtle, but deeply wrong with this.
-                Suppose we do subclass and have loggers that write to files,
-                the screen and the network.
-                Three classes , but that is OK.
-                Now suppose that we want a new logging class that adds message
-                filtering by priority, letting only certain types of messages
-                through according to some configuration file.
+				Il modo più semplice è quello di fare il subclassing di 
+                <code>Log</code> facendo l'overring del metodo <code>message()</code> 
+				con una nuova versione.
+				Funziona a breve termine ma c'è qualcosa di sottile e di profondamente
+				sbagliato in questo.
+                Supponiamo di fare il subclassing e di ottenere i logger per
+				scrivere su file, sullo schermo e sulla rete.
+				Tre classi, ma va bene così.
+				Adesso supponiamo che si voglia una nuova classe di log che
+				aggiunga la funzionalità di filtro in base alla priorità
+				per consentire solo alcuni tipi di messaggio in funzione di un
+				qualche file di configurazione.
             </p>
             <p>
-                We are stuck. If we subclass again, we have to do it for all
-                three classes, giving us six classes.
-                The amount of duplication is horrible.
+				Siamo incastrati. Se applichiamo di nuovo il subclassing dobbiamo
+				farlo per 3 classi e finiamo per ottenerne 6.
+                La quantità di duplicazione è orribile.
             </p>
             <p>
-                So are you now wishing that PHP had multiple inheritence?
-                Well, here that would reduce the short term workload, but
-                complicate what should be a very simple class.
-                Multiple inheritance, even when supported, should be used
-                extremely carefully as all sorts of complicated entanglements
-                can result.
-                Treat it as a loaded gun.
-                In fact, our sudden need for it is telling us something else - perhaps
-                that we have gone wrong on the conceptual level.
+				Desideriamo forse che PHP avesse l'ereditarietà multipla?
+				Be', questo ridurrebbe il lavoro, a breve termine ma complicherebbe
+				quella che dovrebbe essere una classe molto semplice.
+				L'ereditarietà multipla, anche quando è supportata, dovrebbe
+				essere usata con estrema cautela perché porta ad ogni tipo
+				di complicazione.
+				Consideralo una pistola carico.
+                Infatti, la nostra necessità immediata è quella di ammetere qualcos'altro:
+				forse che abbiamo sbagliato qualcosa a livello concettuale.
             </p>
             <p>
-                What does a logger do?
-                Does it send messages to a file?
-                Does it send messages to a network?
-                Does it send messages to a screen?
-                Nope.
-                It just sends messages (full stop).
-                The target of those messages can be chosen when setting
-                up the log, but after that the
-                logger should be left to combine and format the message
-                elements as that is its real job.
-                We restricted ourselves by assuming that target was a filename.
+				Cosa fa un logger?
+				Invia messaggi ad un file?
+                Invia messaggi alla rete?
+                Invia messaggi ad uno schermo?
+                No.
+                Semplicemente invia messaggi. Punto.
+				Il destinatario di questi messaggi può anche essere
+				sceltro durante l'impostazione del logger ma, dopo tutto,
+				il logger dovrebbe limitarsi a combinare e formattare i
+				messaggi perché solo questo è il suo vero compito.
+				Prima ci siamo posti delle restrizioni assumendo che il destinatario
+				fosse un file.
             </p>
         </section>
-        <section name="writer" title="Abstracting a file to a writer">
+        <section name="writer" title="Astrazione di Writer">
             <p>
-                The solution to this plight is a real classic.
-                First we encapsulate the variation in a class as this will
-                add a level of indirection.
-                Instead of passing in the file name as a string we
-                will pass the &quot;thing that we will write to&quot;
-                which we will call a <code>Writer</code>.
-                Back to the tests...
+				La soluzione per questa triste situazione è un vero classico.
+				Primo, incapsuliamo la variazione in una classe così da aggiungere
+				un livello di isolamento.
+				Invece di passare il nome del file come stringa, passeremo
+				&quot;la cosa a cui bisogna inviare i messaggi&quot;
+                che potremmo chiamare <code>Writer</code>.
+                Torniamo ai test:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -134,20 +136,19 @@
 }
 ?>
 ]]></php>
-                I am going to do this one step at a time so as not to get
-                confused.
-                I have replaced the file names with an imaginary
-                <code>FileWriter</code> class from
-                an imaginary file <em>classes/writer.php</em>.
-                This will cause the tests to crash as we have not written
-                the writer yet.
-                Should we do that now?
+				Procederò un passo alla volta in modo da non confonderci.
+				Ho rimpiazzato il nome dei file con un'immaginaria classe
+				<code>FileWriter</code> definita in un immaginario file
+				<em>classes/writer.php</em>.
+				Questo farà andare in crash i test dal momento che non abbiamo
+				ancora scritto il writer.
+                Dobbiamo farlo subito?
             </p>
             <p>
-                We could, but we don&apos;t have to.
-                We do need to create the interface, though, or we won&apos;t be
-                able to mock it.
-                This makes <em>classes/writer.php</em> looks like...
+				Potremmo, ma non è obbligatorio.
+				Piuttosto, abbiamo bisogno di scriverne l'interfaccia o non avremo
+				modo di fare il mock.
+				Ecco come appare <em>classes/writer.php</em>:
 <php><![CDATA[
 <?php
 class FileWriter {
@@ -160,8 +161,7 @@
 }
 ?>
 ]]></php>
-                We need to modify the <code>Log</code> class
-                as well...
+                Dobbiamo modificare anche la classe <code>Log</code>:
 <php><![CDATA[
 <?php
 require_once('../classes/clock.php');<strong>
@@ -183,34 +183,33 @@
 }
 ?>
 ]]></php>
-                There is not much that hasn&apos;t changed in our now even smaller
-                class.
-                The tests run, but fail at this point unless we add code to
-                the writer.
-                What do we do now?
+				Non c'è molto che sia rimasto inalterato nella nostra nuova classe,
+				più piccola di prima.
+				I test si avviano ma continueranno a fallire a questo punto
+				fino a che non aggiungeremo il codice al writer.
+				Cosa possiamo fare?
             </p>
             <p>
-                We could start writing tests and code the
-                <code>FileWriter</code> class alongside, but
-                while we were doing this our <code>Log</code>
-                tests would be failing and disturbing our focus.
-                In fact we do not have to.
+				Potremmo iniziare a scrivere i test ed il codice di
+                <code>FileWriter</code> insieme, ma nel frattempo i
+				test di <code>Log</code> continuerebbero a fallire
+				e a distrarre la nostra attenzione.
+				In effetti non è quello che dobbiamo fare.
             </p>
             <p>
-                Part of our plan is to free the logging class from the file
-                system and there is a way to do this.
-                First we add a <em>tests/writer_test.php</em> so that
-                we have somewhere to place our test code from <em>log_test.php</em>
-                that we are going to shuffle around.
-                I won&apos;t yet add it to the <em>all_tests.php</em> file,
-                as it is the logging aspect we are tackling right now.
+				Uan parte del nostro piano è liberare la classe di logging
+				dal filesystem e c'è un modo per ottenerlo.
+				Per prima cosa agiungiamo un file <em>tests/writer_test.php</em>
+				così potremo disporre di un posto per ospitare il codice preso da
+                <em>log_test.php</em> che ci stiamo apprestando a mescolare.
+				Non lo aggiungerò ancora al file  <em>all_tests.php</em> file perché
+				è il logging l'argomento da affrontare al momento.
             </p>
             <p>
-                Now I have done that (honest!) we remove any
-                tests from <em>log_test.php</em> that are not strictly logging
-                related and move them to <em>writer_test.php</em> for later.
-                We will also mock the writer so that it does not write
-                out to real files...
+				Adesso che l'ho fatto (onestamente!) elimino tutti i test da <em>log_test.php</em> 
+				che non siano strettamente corrrelati all'attività di logging e li sposto
+				in <em>writer_test.php</em> per uso futuro.
+				Creo anche il mock del writer così che non scriva veramente su un file:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -233,45 +232,46 @@
 }
 ?>
 ]]></php>
-                Yes that really is the whole test case and it really is that short.
-                A lot has happened here...
+				Sì, questo è davvero il test case nella sua interezza ed è
+				veramente così corto.
+				Sono successe molte cose:
                 <ol>
                     <li>
-                        The requirement to create the file only when needed has
-                        moved to the <code>FileWriter</code>.
+						Il requisito di creare un file solo quando necessario è
+						stato spostato in <code>FileWriter</code>.
                     </li>
                     <li>
-                        As we are dealing with mocks, no files are actually
-                        created and so I moved the
-                        <code>setUp()</code> and
-                        <code>tearDown()</code> off into the
-                        <code>FileWriter</code> tests.
+						Stiamo lavorando con dei mock: nessun file viene fisicamente
+						creato e, quindi, ho spostato
+                        <code>setUp()</code> e
+                        <code>tearDown()</code> dentro il test di
+                        <code>FileWriter</code>.
                     </li>
                     <li>
-                        The test now consists of sending a sample message and
-                        testing the format.
+						Il test adesso consiste nell'invio di un messaggio di
+						esempio e nella verifica del formato.
                     </li>
                 </ol>
-                Hang on a minute, where are the assertions?
+                Fermi un attimo: dove sono gli assert?
             </p>
             <p>
-                The mock objects do much more than simply behave like other
-                objects, they also run tests.
-                The <code>expectOnce()</code>
-                call told the mock to expect a single parameter of
-                the string &quot;[Timestamp] Test line&quot; when
-                the mock <code>write()</code> method is
-                called.
-                When that method is called the expected parameters are
-                compared with this and either a pass or a fail is sent
-                to the unit test as a result.
+				Gli oggetti mock fanno molto più che simulare il comportamento di altri oggetti:
+				eseguono anche i test.
+                
+				L'invocazione di <code>expectOnce()</code>
+				comunica al mock di attendersi come unico parametro 
+				la stringa &quot;[Timestamp] Test line&quot; 
+				quando il metodo <code>write()</code> viene chiamato.
+				Quando il metodo viene invocato, il parametro atteso viene
+				confrontato con questo e un messaggio di successo o di fallimento
+				viene inviato allo unit test come risultato.
             </p>
             <p>
-                The other expectation is that <code>write()</code>
-                will be called and called only once.
-                If the method is not called before the end of the test,
-                a failure is generated.
-                We can see all this in action by running the tests...
+				L'altro comportamento atteso è che <code>write()</code>
+				sia chiamato una ed una sola volta.
+				Nel caso il metodo non venga invocato entro la fine del test
+				viene generato un fallimento.
+                Possiamo vedere tutto questo in azione eseguendo i test:
                 <div class="demo">
                     <h1>All tests</h1>
                     <span class="pass">Pass</span>: log_test.php-&gt;Log class test-&gt;testwriting-&gt;Arguments for [write] were [String: [Timestamp] Test line]<br />
@@ -284,89 +284,84 @@
                 </div>
             </p>
         </section>
-        <section name="boundary" title="Boundary classes">
+        <section name="boundary" title="Isolare i setup test">
             <p>
-                Something very nice has happened to the logger besides merely
-                getting smaller.
+				Apparte l'essersi ridotto di dimensioni, qualcosa di molto piacevole
+				è accaduto al logger.
             </p>
             <p>
-                The only things it depends on now are classes that we have written
-                ourselves, and
-                in the tests these are mocked and so there are no dependencies
-                on anything other than our own PHP code.
-                No writing to files or waiting for clocks to tick over.
-                This means that the <em>log_test.php</em> test case will
-                run as fast as the processor will carry it.
-                By contrast the <code>FileWriter</code>
-                and <code>Clock</code> classes are very
-                close to the system.
-                This makes them harder to test as real data must be moved
-                around and painstakingly confirmed, often by ad hoc tricks.
+				Gli unici elementi da cui adesso dipende sono le classi che abbiamo direttamente
+				scritto e queste, nei test, sono sostituite da mock così che non esiste
+				più alcuna dipendenza se non dal nostro stesso codice PHP.
+				Non c'è scrittura su file o attesa di ticchetii di orologio.
+				In altre parole, il test case <em>log_test.php</em> verrà eseguito alla massima
+				velocità supportata dal processore.
+				Al contrario, le classi <code>FileWriter</code> e <code>Clock</code> sono molto legate
+				al sistema e questo le rende più difficili da collaudare perché
+				i dati reali devono essere spostati ed assiduamente controllati,
+				spesso con trucchi ad hoc.
             </p>
             <p>
-                Our last refactoring has helped a bit.
-                The hard to test classes on the boundary of the application
-                and the system are now smaller, as the I/O code has
-                been further separated from the domain logic.
-                They are direct mappings to PHP operations:
-                <code>FileWriter::write()</code> maps
-                to PHP <code>fwrite()</code> with the
-                file opened for appending and
-                <code>Clock::now()</code> maps to
-                PHP <code>time()</code>.
-                This makes debugging easier.
-                It also means that these classes will change less often.
+				L'ultimo refactoring che abbiamo effettuato ci è stato utile.
+				La difficoltà nel collaudare le classi all'interfaccia tra
+				l'applicazione ed il sistema sono stati ridotti dal momento che
+				il codice di I/O e stato ulteriormente sepatato dalla logica
+				di dominio.
+				Esistono delle corrispondenze dirette con le operazioni PHP:
+                <code>FileWriter::write()</code> corrisponde al comando PHP
+				<code>fwrite()</code> con il file aperto in modalità append
+				e
+                <code>Clock::now()</code> corrisponde a <code>time()</code>.
+                Questo facilita enormemente il debugging.
+				Significa anche che queste classi cambieranno più raramente.
             </p>
             <p>
-                If they don&apos;t change a lot then there is no reason to
-                keep running the tests for them.
-                This means that tests for the boundary classes can be moved
-                off into there own test suite leaving the other unit tests
-                to run at full speed.
-                In fact this is what I tend to do and the test cases
-                in <a href="simple_test.php">SimpleTest</a> itself are
-                divided this way.
+				Se non cambieranno spesso allora non c'è ragione per
+				continuare ad eseguire i loro test.
+				Ciò implica che i test per le classi di interfaccia possono essere
+				trasferite in test suite dedicate in modo da permettere alle test
+				suite delle unità di essere eseguite al massimno della velocità.
+				In effeti è quello che cerco di fare e gli stessi test case di
+                <a href="simple_test.php">SimpleTest</a> sono suddivisi in questo modo.
             </p>
             <p>
-                That may not sound like much with one unit test and two
-                boundary tests, but typical applications can have
-                twenty boundary classes and two hundred application
-                classes.
-                To keep the unit tests running at full speed you will want
-                to keep them separate.
+				Può non sembrare molto per il caso di uno unit test con due
+				test di interfaccia ma, tipicamente, le applicazioni hanno
+				decine di classi di interfaccia e centinaia di classi di applicazione.
+				Per garantire che le unit test vengano eseguite al massimo della velocità
+				si cercherà sempre di mantenerle separate.
             </p>
             <p>
-                Another benefit of this separation is that you are left
-                with the smaller test suite for all your dependencies.
-                Suppose you want to set up a server for your application
-                and you want to make sure that all underlying components,
-                directories and configuration are correct.
-                You no longer need to run the entire test suite to find out,
-                just run the tests for your boundary classes.
-                For this reason, this test suite is often called the
-                &quot;setup tests&quot;.
-                Hand them to your system administrator, and they can set up
-                your server for you.
+				Un ulteriore vantaggio di questa separazione è che in tutti
+				i casi di dipendenza si ottengono test suite più ridotte.
+				Supponiamo si voglia impostare un server per l'applicazione e che
+				ci si voglia assicurare che le componenti sottostanti, le directory e
+				le configurazioni siano corretti.
+				Non ci sarà il bisogno di eseguire tutti i test: sarà sufficiente eseguire
+				i test delle classi di interfaccia.
+				Per questo motivo la test suite per lo scopo verrà chiamata
+                &quot;setup test&quot;.
+				Consegnala al tuo amministratore di sistema e lascia che venga
+				utilizzata per configurare il server per te.
             </p>
             <p>
-                Besides, separating off decisions of which system components
-                to use is good development.
-                Being able to change the underlying dependencies easily is a
-                good thing.
-                Perhaps all this mocking is
-                <a href="improving_design_tutorial.php">improving our design</a>?
+				Apparte questo, isolare le decisioni di quali componenti del sistema
+				utilizzare è una buona pratica nello sviluppo.
+				Possedere l'abilità di modificare le dipendenze sottostanti con facilità
+				è un bene. E' possibile che il mocking una pratica che 
+                <a href="improving_design_tutorial.php">migliora il design</a>?
             </p>
         </section>
     </content>
     <internal>
         <link>
-            <a href="#variation">Handling variation</a> in our logger.
+            <a href="#variation">Gestire le variazioni nel logger.</a>
         </link>
         <link>
-            Abstracting further with a <a href="#writer">mock Writer</a> class.
+            Aumentare l'astrazione con una <a href="#writer">classe mock di Writer</a>.
         </link>
         <link>
-            Separating out<a href="#boundary">setup tests</a> cleans things up.
+            <a href="#boundary">Isolare i setup test</a> per mantenere l'ordine.
         </link>
     </internal>
     <external>

Modified: simpletest/trunk/docs/source/it/improving_design_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/improving_design_tutorial.xml	2009-09-28 14:21:30 UTC (rev 1955)
+++ simpletest/trunk/docs/source/it/improving_design_tutorial.xml	2009-09-29 14:05:59 UTC (rev 1956)
@@ -6,16 +6,15 @@
         test first with mock objects
     </long_title>
     <content>
-        <section name="mock" title="Mock now, code later">
+        <section name="mock" title="Scrivi i mock subito e il codice dopo">
             <p>
-                I lied.
+                Ho mentito.
             </p>
             <p>
-                I haven&apos;t created a writer test at all, only the
-                <code>FileWriter</code> interface that I showed
-                earlier.
-                In fact I&apos;ll go one step further away from a finished article and assume
-                only an abstract writer in <em>classes/writer.php</em>...
+				Non ho creato affatto il test del writer, solo l'interfaccia
+				di <code>FileWriter</code> che ho mostrato prima.
+				In effetti, mi allonerò ancora dalla fine dell'articolo e
+				assumerò che ci sia unicamente la classe abstract in <em>classes/writer.php</em>:
 <php><![CDATA[
 <?php
 class <strong>Writer</strong> {
@@ -28,7 +27,7 @@
 }
 ?>
 ]]></php>
-                The corresponding test changes are...
+                I cambiamenti relativi nel test sono:
 <php><![CDATA[
 <?php
 require_once(dirname(__FILE__) . '/simpletest/autorun.php');
@@ -51,110 +50,118 @@
 }
 ?>
 ]]></php>
-                In order to use the logging class we would need to code a file
-                writer or other sort of writer, but at the moment we are only
-                testing and so we do not yet need it.
-                So, in other words, using mocks we can defer the creation of
-                lower level objects until we feel like it.
-                Not only can we design top down, but we can test top down too.
+				Al fine di usare la classe di log è necessario del codice nel file del
+				writer o un'altro tipo di writer ma per il momento stiamo solo
+				collaudando e non ne abbiamo bisogno.
+				Così, in altre parole, usando i mock possiamo procrastinare
+				quanto desideriamo la creazione di oggeti di più basso livello.
+				Non solo possiamo fare un design top down, ma possiamo
+				anche collaudare in top down.
             </p>
         </section>
-        <section name="bridge" title="Approaching the bridge">
+        <section name="bridge" title="Avviciniamoci al design pattern bridge">
             <p>
-                Imagine for the moment that we had started the logging class
-                from another direction.
-                Pretend that we had coded just enough of the <code>Log</code>
-                to realise we needed a <code>Writer</code> somehow.
-                How would we have included it?
+				Immaginiamo per un momento di aver iniziato la classe di logging
+				a partire da un'altra direzione..
+                Supponiamo di avere abbastanza codice della classe <code>Log</code>
+				da renderci conto che abbiamo bisogno in qualche modo di <code>Writer</code>.
+				Come dovremmo includerlo?
             </p>
             <p>
-                Well, inheriting from the writer would not have allowed us to mock it
-                from the testing point of view.
-                From the design point of view we would have been restricted to
-                just one writer without multiple inheritence.
+				Be', se avessimo ereditato da writer non avremmo potuto farne il
+				mock, dal punto di vista del collaudo.
+				Dal punto di vista del design avremmo avuto la limitazione di un solo
+				writer, senza l'ereditarietà multipla.
             </p>
             <p>
-                Creating the writer internally, rather than passing it in the constructor,
-                by choosing a class name is possible, but we would have less control
-                of the mock object set up.
-                From the design point of view it would have been nearly impossible
-                to pass parameters to the writer in all the different formats ever needed.
-                You would have to have the writer restricted to say a hash or complicated
-                string describing the target details.
-                Needlessly complicated at best.
+				La generazione del writer internamente alla classe  scegliendo il nome,
+				in alternativa al passaggio dentro il costruttore, è possibile ma 
+				conduce ad un minore controllo sulla configurazione dell'oggetto mock.
+				
+				Dal punto di vista del design sarebbe stato quasi impossibile passare
+				dei parametri al writer per tutti i differenti fornati possibili.
+				Sarebbe stato necessario limitare il writer ad un hash o a complicate
+				stringhe per descrivere i dettagli del destinatario.
+				Nella migliore ipotesi, inutilmente complicato.
             </p>
             <p>
-                Using a factory method to create the writer internally would be
-                possible, but would mean subclassing it for testing so that the factory
-                method could be replaced with one returning a mock.
-                More work from the test point of view, although still possible.
-                From the design point of view it would mean a new logger subclass
-                for every type of writer that we want to use.
-                This is called a parallel class hiearchy and obviously involves
-                duplication.
-                Yuk.
+				Sarebbe possibile usare un factory method per creare internamente
+				il writer ma questo significherebbe fare il subclassing per i
+				collaudi in modo da rimpiazzare il factory method con uno
+				alternativo che restituisse il mock.
+				Più lavoro per il collaudo, anche se sempre possibile.
+				Dal punto di vista del design significherebbe nessuna necessità
+				di fare un subclass per ogni tipo di writer che si volesse
+				usare.
+				Questo si chiama gerarchia parallela delle classi e, ovviamente, 
+				comporta duplicazione. Yuk.s
             </p>
             <p>
-                At the other extreme, passing or creating the writer on every
-                message would have been repetitive and reduced the
-                <code>Log</code> class code to a single
-                method, a sure sign that the whole class has become redundant.
+				All'altro estremo, passare o creare il writer ad ogni
+				messaggio sarebbe ripetitivo e ridurrebbe il codice della
+				classe <code>Log</code> ad un singolo metodo, indice chiaro
+				che la classe stessa sarebbe ridondante.
             </p>
             <p>
-                This tension between ease of testing and avoiding repetition
-                has allowed us to find a flexible and clean design.
-                Remember our brief yearning for multiple inheritence?
-                We have replaced it with polymorphism (lots of writers) and separated the
-                logging hierachy from the writing hierarchy.
-                We connect the two through this simpler <code>Log</code>
-                by aggregation.
-                This trick is actually a design pattern called a &quot;Bridge&quot;.
+				La tensione tra la facilità del collaudo e l'evitare le
+				ripetizioni ha permesso di trovare un design pulito e
+				flessibile.
+				Ricordi il nostro breve desiderio di ereditarietà multipla?
+				L'abbiamo rimpiazzata con il polimorfismo (molti writer) e con
+				la separazione della gerarchia riguardante il log dalla gerarchia
+				riguardante la scrittura.
+				Dopo di che, connettiamo le due con una semplice classe
+                <code>Log</code> tramite l'aggregazione.
+				Questo trucchetto, in effetti, è un design pattern chiamato 
+                &quot;Bridge&quot;.
             </p>
             <p>
-                So we have been pushed by test code (we haven&apos;t written much else yet)
-                into a design pattern.
-                Think about this for a second.
-                Tests improve code quality, certainly in my case, but this is
-                something far more profound and far more powerful.
+				Così siamo stati trascinati, partendo dal codice di test (e oltretutto
+				non abbiamo scritto un granché) verso i design pattern.
+				Riflettici un secondo.
+				Non solo i test migliorano la qualità del codice, sicuramente nel mio
+				personale caso, ma fanno qualcosa di molto più profondo e più
+				potente.
             </p>
             <p>
-                Testing has improved the design.
+                I test migliorano il design.
             </p>
         </section>
-        <section name="design" title="Mock down design">
+        <section name="design" title="Design dell'applicazione con i mock">
             <p>
-                Creating a mock object is as easy as creating the interface in text
-                form.
-                If you have UML or other tools that create these interfaces for you,
-                then you have an even more flexible route to quickly generate
-                test objects.
-                Even if you do not, you can switch from white board drawing, to
-                writing a test case, to writing a mock, to generating an interface
-                which takes us back to the whiteboard drawing again, fairly easily.
-                Like refactoring, design, code and test become unified.
+				Creare un oggetto mock è semplice quanto creare un'interfaccia in forma
+				testuale.
+				Se disponi di un tool UML o di altri strumenti che creano queste
+				interfacce per te allora hai un modo ancora più flessibile per
+				generare rapidamente gli oggetti per il collaudo.
+				Anche se questo non è il tuo caso, puoi sempre passare facilmente dal
+				disegnare su un foglio bianco allo scrivere un test case, sviluppare un
+				mock, generare un'interfaccia che ti porti di nuovo a disegnare sul 
+				foglio e così via, facilmente.
+				E' come se refactoring, design, collaudo e sviluppo fossero stati unificati
             </p>
             <p>
-                Because mock objects work top down they can be bought into the design
-                more quickly than normal refactoring, which requires at least
-                partially working code before it kicks in.
-                This means that the testing code interacts with the design faster
-                and this means that the design quality goes up sooner.
+				Siccome gli oggetti mock lavorano in top down possono essere adottati
+				nel design molto più facilmente dell'ordinario refactoring il quale richiede
+				prima di essere applicato che ci sia almeno un codice parzialmente funzionante.
+                Ciò implica che il codice di test interagisce con il design molto più
+				velocemente e che la qualità del design migliora più rapidamente.
             </p>
             <p>
-                A unit tester is a coding tool.
-                A unit tester with mock objects is a design tool.
+				Uno unit tester è uno strumento di sviluppo.
+				Uno unit tester con oggetti mock è un design tool.
             </p>
         </section>
     </content>
     <internal>
         <link>
-            <a href="#mock">Mock now</a>, code later.
+            <a href="#mock">Fai i mock subito</a>, scrivi il codice dopo.
         </link>
         <link>
-            We derive <a href="#bridge">the bridge pattern</a>.
+            Deriviamo il <a href="#bridge">bridge pattern</a>.
         </link>
         <link>
-            <a href="#design">Designing and testing</a> hand in hand.
+            <a href="#design">Unire design e collaudo</a>.
         </link>
     </internal>
     <external>

Modified: simpletest/trunk/docs/source/it/mock_objects_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/mock_objects_tutorial.xml	2009-09-28 14:21:30 UTC (rev 1955)
+++ simpletest/trunk/docs/source/it/mock_objects_tutorial.xml	2009-09-29 14:05:59 UTC (rev 1956)
@@ -5,12 +5,11 @@
     <content>
         <section name="refactor" title="Refactoring the tests again">
             <p>
-                Before more functionality is added there is some refactoring
-                to do.
-                We are going to do some timing tests and so the
-                <code>TimeTestCase</code> class definitely needs
-                its own file.
-                Let&apos;s say <em>tests/time_test_case.php</em>...
+				Prima di aggiungere nuove funzioanlità c'è del refactoring da fare.
+				Abbiamo da eseguire dei test riguardanti il tempo e 
+				la classe <code>TimeTestCase</code> ha definitivamente
+				bisogno di un suo proprio file.
+				Chiamiamolo <em>tests/time_test_case.php</em>:
 <php><![CDATA[
 <strong><?php
 require_once('simpletest/unit_tester.php');
@@ -27,15 +26,15 @@
 }
 ?></strong>
 ]]></php>
-                We can then <code>require()</code> this file into
-                the <em>all_tests.php</em> script.
+				Potremmo includerlo con <code>require()</code> nello script
+                <em>all_tests.php</em>.
             </p>
         </section>
-        <section name="timestamp" title="Adding a timestamp to the Log">
+        <section name="timestamp" title="Aggiungere un timestamp al log">
             <p>
-                I don&apos;t know quite what the format of the log message should
-                be for the test, so to check for a timestamp we could do the
-                simplest possible thing, which is to look for a sequence of digits.
+				Siccome non sappiamo con esattezza quale sia il formato del messaggio
+				di log durante il test, verificheremo il più semplice caso, quello di una
+				sequenza di numeri.
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');<strong>
@@ -73,10 +72,10 @@
 }
 ?>
 ]]></php>
-                The test case creates a new <code>Log</code> object and writes a message.
-                We look for a digit sequence and then test it against the current
-                time using our <code>Clock</code> object.
-                Of course it doesn&apos;t work until we write the code.
+				Il test case genera un nuovo oggetto <code>Log</code> e scrive un messaggio.
+				Cerchiamo una sequenza di numeri e la confrontiamo con l'ora corrente
+				utilizzando l'oggetto <code>Clock</code>.
+				Naturalmente, niente funzionerà prima che si scriva il codice.
                 <div class="demo">
                     <h1>All tests</h1>
                     <span class="pass">Pass</span>: log_test.php->Log class test->testappendingtofile->Expecting [/Test line 1/] in [Test line 1]<br />
@@ -92,16 +91,15 @@
                     <div style="padding: 8px; margin-top: 1em; background-color: red; color: white;">3/3 test cases complete.
                     <strong>6</strong> passes, <strong>2</strong> fails and <strong>2</strong> exceptions.</div>
                 </div>
-                The test suite is still showing the passes from our earlier
-                modification.
+				La test suite continua a mostrare i successi della nostra prima modifica.
             </p>
             <p>
-                We can get the tests to pass simply by adding a timestamp
-                when writing out to the file.
-                Yes, of course all of this is trivial and
-                I would not normally test this fanatically, but it is going
-                to illustrate a more general problem.
-                The <em>log.php</em> file becomes...
+				Possiamo fare in modo che i test passino semplicemente aggiungendo un
+				timestemp al momento della scrittura del file.
+				Sì, naturalmente tutto questo è insignificante e
+				normalmente non collaudo a questi livelli da fanatismo, ma l'esempio
+				è buono per illustrare un problema più generale.
+                Il file <em>log.php</em> diventa:
 <php><![CDATA[
 <?php<strong>
 require_once('../classes/clock.php');</strong>
@@ -122,79 +120,81 @@
 }
 ?>
 ]]></php>
-                The tests should now pass.
+                Il test dovrebbe passare.
             </p>
             <p>
-                Our new test is full of problems, though.
-                What if our time format changes to something else?
-                Things are going to be a lot more complicated to test if this
-                happens.
-                It also means that any changes to the clock class time
-                format will cause our logging tests to fail also.
-                This means that our log tests are tangled up with the clock tests
-                and extremely fragile.
-                It lacks cohesion, which is the same as saying it is not
-                tightly focused, testing facets of the clock as well as the log.
-                Our problems are caused in part because the clock output
-                is unpredictable when all we really want to test is that the
-                logging message contains the output of <code>Clock::now()</code>.
-                We don&apos;t really care about the contents of that method call.
+				Il nostro nuovo test, tuttavia, è pieno di problemi.
+				Cosa accadrebbe se il formato di stampa dell'ora dovesse
+				cambiare?
+                Le cose diventerebbero un bel po' più complicate se questo accadesse.
+				Comportebbe anche modificare il formato delle ore della classe
+				clock, il che porterebbe altri test a fallire.
+				In altre parole, i test di log sono accoppiati con i test di
+				clock e sono estremamente fragili.
+				Mancano di coesione, il che equivale a dire che non sono
+				molto a fuoco su un solo obiettivo, dal momento che collaudano
+				anche aspetti del clock oltre a quelli del log.
+				I nostri problemi sono in parte causati dal fatto che l'output
+				di clock è imprevedibile, anche se quel che si intendeva realmente
+				fare era collaudare che il messaggio del log contenesse l'output di
+				<code>Clock::now()</code>, qualunque esso fosse.
+				Non ci interessa davvero il contenuto di quella invocazione di metodo.
             </p>
             <p>
-                From the testing point of view, everything we've just done is
-                wrong.
+				Dal punto di vista del il collaudo, tutto quel che è stato fatto
+				fin'ora è errato.
             </p>
             <p>
-                Can we make that call predictable?
-                We could if we could get the log to use a dummy version
-                of the clock for the duration of the test.
-                The dummy clock class would have to behave the same way
-                as the <code>Clock</code> class
-                except for the fixed output from the
-                <code>now()</code> method.
-                Hey, that would even free us from using the
-                <code>TimeTestCase</code> class!
+				Possiamo rendere la chiamata predicibile?
+                Potremmo se solo potessi indurre log ad usare una versione
+				fasulla di clock almeno per la durata del test.
+				La falsa classe clock dovrebbe comportarsi come la classe
+				<code>Clock</code> apparte per l'output fisso del metodo
+                <code>now()</code>.
+				Hey, questo ci libererebbe perfino dall'uso della classe
+                <code>TimeTestCase</code>!
             </p>
             <p>
-                We could write such a class pretty easily although it is
-                rather tedious work.
-                We just create another clock class with same interface
-                except that the <code>now()</code> method
-                returns a value that we can change with some other setter method.
-                That is quite a lot of work for a pretty minor test.
+				Potremmo scriverefacilmente una classe di questo tipo anche
+				se il lavoro risulterebbe noioso.
+				Creeremmo un'altra classe clock con la stessa interfaccia
+				ma con il metodo <code>now()</code> pensato per restituire
+				un valore che potremmo essere in grado di modificare attraverso
+				degli appositi metodi setter.
+				E' un bel lavoro, per un test di minore entità.
             </p>
             <p>
-                Except that it is really no work at all.
+				Tranne il fatto che, nella realtà, non c'è affatto alcuno
+				sforzo da fare.
             </p>
         </section>
         <section name="mock" title="A mock clock">
             <p>
-                To reach instant testing clock nirvana we need
-                only three extra lines of code...
+				Per raggiungere istantaneamente il nirvana del clock per i test
+				abbiamo bisogno solo di tre righe di codice:
 <php><![CDATA[
 require_once('simpletest/mock_objects.php');
 ]]></php>
-                This includes the mock generator code.
-                It is simplest to place this in the <em>all_tests.php</em>
-                script as it gets used rather a lot.
+				Questa include il codice del generatore di mock.
+				La cosa più semplice è mettere questa riga in <em>all_tests.php</em>
+				dal momento che verrà usata spesso.
 <php><![CDATA[
 Mock::generate('Clock');
 ]]></php>
-                This is the line that does the work.
-                The code generator scans the class for all of its
-                methods, creates code to generate an identically
-                interfaced or inherited class, but with the name
-                &quot;Mock&quot; added.
-                It then then <code>eval()</code>$apos;s the new code to
-                create the new class.
+				Questa è la linea che fa il vero lavoro.
+				Il generatore di codice scansiona tutti i metodi della classe ,
+				crea il codice per generare un'interfaccia identica o una classe
+				ereditata ed aggiunge il prefisso &quot;Mock&quot; al nome.
+                Dopo di che, esegue con <code>eval()</code> il codice per
+				creare la nuova classe.
 <php><![CDATA[
 $clock = new MockClock($this);
 ]]></php>
-                This line can be added to any test method we are interested in.
-                It creates the dummy clock ready to receive our instructions.
+				Questa linea può essere aggiunta a qualsiasi metodo di test.
+				Genera un oggetto clock fasullo pronto per ricevere istruzioni.
             </p>
             <p>
-                Our test case is on the first steps of a radical clean up...
+				Il nostro test è il primo passo per una radicale pulizia:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');<strong>
@@ -234,20 +234,20 @@
 }
 ?>
 ]]></php>
-                This test method creates a <code>MockClock</code>
-                object and then sets the return value of the
-                <code>now()</code> method to be the string
+				Questo metodo di test genera un oggetto <code>MockClock</code>
+				ed imposta valore di ritorno del metodo <code>now()</code> perché
+				sia la stringa
                 &quot;Timestamp&quot;.
-                Every time we call <code>$clock->now()</code>
-                it will return this string.
-                This should be easy to spot.
+				Ogni volta che <code>$clock->now()</code> viene invocato
+				restituirà quella stringa.
+				Questo dovrebbe essere facile da comprendere.
             </p>
             <p>
-                Next we create our log and send a message.
-                We pass into the <code>message()</code>
-                call the clock we would like to use.
-                This means that we will have to add an optional parameter to
-                the logging class to make testing possible...
+				Successivamente, creiamo log e gli inviamo un messaggio.
+				Passiamo a <code>message()</code> il clock
+				che desideriamo usare.
+				Questo comporta che per rendere possibile il collaudo ci sia
+				la necessità di un parametro aggiuntivo alla classe di log:
 <php><![CDATA[
 class Log {
     private $path;
@@ -264,57 +264,57 @@
     }
 }
 ]]></php>
-                All of the tests now pass and they test only the logging code.
-                We can breathe easy again.
+				Adesso tutti i test passano e collaudano solo il codice del log.
+				Possiamo tirare nuovamente un sospiro di sollievo.
             </p>
             <p>
-                Does that extra parameter in the <code>Log</code>
-                class bother you?
-                We have changed the interface just to facilitate testing after
-                all.
-                Are not interfaces the most important thing?
-                Have we sullied our class with test code?
+				Ti disturba il parametro extra in <code>Log</code>?
+				Dopo tutto, abbiamo modificato l'interfaccia al solo scopo di facilitare il
+				collaudo.
+                Non erano le interfaccie le cose più importanti?
+				Non abbiamo sporcato la nostra classe con il codice di test?
             </p>
             <p>
-                Its not ideal, but consider this.
-                Next chance you get, look at a circuit board, perhaps the motherboard
-                of the computer you are looking at right now.
-                On most boards you will find the odd empty hole, or solder
-                joint with nothing attached or perhaps a pin or socket
-                that has no obvious function.
-                Chances are that some of these are for expansion and
-                variations, but most of the remainder will be for testing.
+				Senza dubbio non è il caso ideale ma considera questo:
+				alla prossima occasione che ti si presentam dai un occhio ad un
+				circuito stampato, magari quello della scheda madre del computer dal
+				quale stai leggendo proprio adesso.
+				Nella maggior parte delle schede troverai degli strani fori o dei punti
+				di saldatura inutilizzati o forse dei pin o dei socket che non 
+				sembrano avere una funzione certa.
+				C'è la possibilità che alcune di queste servano per
+				l'espansione e la modifica della scheda ma la maggior parte
+				è lì per i collaudi.
             </p>
             <p>
-                The factories making the boards many times over wasting material
-                on parts that do not add to the final function.
-                If hardware engineers can make this sacrifice of elegance I am
-                sure we can too.
-                Our sacrifice wastes no materials after all.
+				Le fabbriche che producono le schede in migliaia di esemplari consumano
+				materiale su parti che non aggiungono alcuna funzione al prodotto finale.
+				Se gli ingegneri elettronici possono fare questo sacrificio di eleganza
+				sono certo che possiamo farlo anche noi.
+				Del resto, il nostro sacrificio non spreca nemmeno materiale.
+                
             </p>
             <p>
-                Still bother you?
-                Actually it bothers me too.
-                If it really bothers you, then move the creation of the clock
-                into another protected factory method.
-                Then subclass the clock for testing and override the
-                factory method with one that returns the mock.
-                Your tests are clumsier, but your interface is intact.
+                Ti disturba lo stesso?
+                A dire la verità disturba anche me.
+				Se la cosa davvero ti dà fastidio, allora sposta la creazione dell'orologio
+				dentro un apposito metodo di factoring protetto.
+				Dopo di che, estendi la classe clock per i collaudi e
+				fai l'overriding del metodo factory con uno che restituisca il mock.
+				I test risulteranno più scomodi ma l'interfaccia resterà intatta.
             </p>
             <p>
-                I leave the decision to you, but note that we have some
-                automation in the next section that helps make the subclassing
-                easier.
+				La decisione è personale ma nota che nella prossima sezione
+				si vedranno alcuni automatismi per facilitare il subclassing.
             </p>
         </section>
     </content>
     <internal>
         <link>
-            <a href="#refactor">Refactoring the tests</a> so we can reuse
-            our new time test.
+            <a href="#refactor">Refactoring dei test</a> per il riutilizzo dei test.
         </link>
-        <link>Adding <a href="#timestamp">Log timestamps</a>.</link>
-        <link><a href="#mock">Mocking the clock</a> to make the test cohesive.</link>
+        <link><a href="#timestamp">Aggiungere un timestamp ai log</a>.</link>
+        <link><a href="#mock">Mock dell'orologio</a> per rendre il test più coeso.</link>
     </internal>
     <external>
         <link>


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 1958
          http://simpletest.svn.sourceforge.net/simpletest/?rev=1958&view=rev
Author:   arialdomartini
Date:     2009-09-30 14:42:38 +0000 (Wed, 30 Sep 2009)

Log Message:
-----------
Some minor fixes

Modified Paths:
--------------
    simpletest/trunk/docs/source/it/first_test_tutorial.xml
    simpletest/trunk/docs/source/it/simple_test.xml

Modified: simpletest/trunk/docs/source/it/first_test_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/first_test_tutorial.xml	2009-09-29 14:06:36 UTC (rev 1957)
+++ simpletest/trunk/docs/source/it/first_test_tutorial.xml	2009-09-30 14:42:38 UTC (rev 1958)
@@ -5,9 +5,9 @@
     <content>
         <introduction>
             <p>
-				Nel caso tu sia inesperto di unit testing, si raccomanda
+				Nel caso tu sia inesperto di unit testing, la raccomandazione è
 				di provare di volta in volta il codice che si incontrerà durante lettura del tutorial:
-                non richiede molto da scrivere e fornisce la sensazione del ritmo
+                non richiede molto da scrivere e fornisce la sensazione di quale sia il ritmo
 				della programmazione guidata dal collaudo.
             </p>
             <p>
@@ -18,20 +18,20 @@
 				le varie posizioni.
             </p>
         </introduction>
-        <section name="new" title="A new test case">
+        <section name="new" title="Un nuovo test case">
             <p>
-				Il rapido <a local="{{simple_test}}">esempio introduttivo</a>
-				ha mostrato il collaudo di unità di una semplice classe per fare i log.
+				Nel <a href="start-testing.html">tutorial rapido</a>
+				è stato mostrato il collaudo di unità applicato ad una semplice classe di log.
 				In questo tutorial su SimpleTest ho intenzione di provare
 				a raccontare l'argomento dello sviluppo della classe nella sua interezza.
 				La classe dell'esempio è piccola e semplice e nel corso dell'introduzione
-				riceverà probabilmente più attenzione di quanto ne riceverebbe
+				riceverà probabilmente più attenzione di quanta ne riceverebbe
 				realmente in produzione.
 				Ma perfino una classe minuscola come questa richiederà decisioni sul
 				design di soprendente difficoltà.
             </p>
             <p>
-				Può darsi anche troppo difficili?
+				Può darsi decisioni fin troppo difficili?
                 Piuttosto che tentare di disegnare il tutto fin dall'inizio,
 				si partirà con un requisito noto: il fatto che si vuole
 				scrivere un messaggio su un file.
@@ -63,19 +63,19 @@
                 <code>UnitTestCase</code>.
 				Recupera tutte le classi dei test definite nel file corrente
 				e le esegue automagicamente.
-				Per ottenere questo risultato imposta un hadler di uscita dallo
+				Per ottenere questo risultato, imposta un handler di uscita dallo
 				script PHP.
-				Approfondiremo l'argomento più tardi quando si affronterà
+				Approfondiremo il discorso più tardi quando si affronterà
 				l'argomento della modifica dell'output.
             </p>
             <p>
 				I test stessi sono raccolti in classi di test case.
-				La classe dell'esempio, <code>TestOfLogging</code>, estende come nel caso
-				più tipico <code>UnitTestCase</code>.
+				La classe dell'esempio, <code>TestOfLogging</code>, estende, come nel caso
+				più tipico, <code>UnitTestCase</code>.
 				Quando il test case viene invocato, l'autorunner si metterà alla ricerca
 				dei metodi della classe il cui nome inizi per &quot;test&quot;.
-				Ciascuno di questi metodi verrà eseguito nell'ordine in cui sono
-				definiti nella classe.
+				Ciascuno di questi metodi verrà eseguito nell'ordine in cui è
+				definito nella classe.
             </p>
             <p>
 				L'unico metodo attualmente presente nella classe è 
@@ -83,7 +83,7 @@
                 Non contiene ancora niente.
             </p>
             <p>
-				Adesso, la definizione vuota del metodo non esegue alcunché.
+				Adesso, la definizione vuota del metodo non può eseguire alcunché.
 				Abbiamo bisogno di riempirla con del codice.
 				La classe <code>UnitTestCase</code>, normalmente, è
 				pensata per generare durante il suo funzionamento degli eventi  che 
@@ -109,21 +109,21 @@
 ]]></php>
             </p>
             <p>
-				Probabilmente starai pensando che si tratta di troppo codice
+				Starai probabilmente pensando che si tratti di troppo codice
 				per un singolo collaudo e su questo concordo.
 				Non temere. Questo è un costo una tantum a da questo momento in poi
 				i test saranno uno scherzo da aggiungere.
-				E saranno ancora più semplici con i meccanismo che vedremo
+				E saranno ancora più semplici con i meccanismi che vedremo
 				più avanti.
             </p>
             <p>
 				Può anche darsi che tu abbia pensato che
                 <code>testFirstLogMessagesCreatesFileIfNonexistent</code>
-				sia un nome di metodo orribile e troppo lungo.
+				sia un nome orribile e troppo lungo per un metodo.
 				Generalmente questo sarebbe vero, ma in questo contesto è una
 				buona scelta.
 				Non capiterà mai più di dover digitare nuovamente questa stringa ed
-				il nome lungo ci permette di risparmiarci commenti e specifiche.
+				il nome lungo permette di risparmiare commenti e specifiche.
             </p>
             <p>
 				Adesso è il momento della nostra prima decisione.
@@ -147,7 +147,7 @@
 				Il test di per se' è minimale.
 				Per prima cosa elimina qualsiasi file di test dovesse
 				essere rimasto da precedenti esecuzioni.
-				Le decisioni di design vengono rapidamente e tutte insieme.
+				Le decisioni di design sopraggiungono rapidamente e tutte insieme.
 				
 				La nostra classe si chiama <code>Log</code> ed
 				accetta il path del file nel costruttore.
@@ -155,7 +155,7 @@
 				un messaggio con il metodo
                 <code>message()</code>.
 				Sfortunatamente, la capacità di scegliere nomi originali
-				non è una caratteristica molto richiesta negli sviluppatori
+				non è una caratteristica molto richiesta agli sviluppatori
 				software.
             </p>
             <p>
@@ -214,9 +214,9 @@
             <p>
 				Il coinventore di <a href="http://www.extremeprogramming.org/">eXtreme Programming</a>,
 				Kent Beck, ha pubblicato un nuovo manifesto.
-				Il libro si intotola
-                The book is called <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/ref=lib_dp_TFCV/102-2696523-7458519?v=glance&amp;s=books&amp;vi=reader#reader-link">Test driven development</a>
-				o TDD e promuove lo unit testing ad una posizione chiave nel design di software.
+				Il libro si intitola
+                <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/ref=lib_dp_TFCV/102-2696523-7458519?v=glance&amp;s=books&amp;vi=reader#reader-link">Test driven development</a>
+				(TDD) e promuove lo unit testing ad una posizione chiave nel design di software.
 				In breve, l'idea è di scrivere  dei piccoli test prima e
 				solo dopo occuparsi della scrittura del codice.
 				Per qualsiasi codice.
@@ -224,10 +224,10 @@
             </p>
             <p>
 				Scrivi un nuovo test e fai in modo che passi con successo.
-				Quello che otterrai e qualche ridondanza e generalmente del codice
+				Quello che otterrai all'inizio è un po' di ridondanza e, generalmente, del codice
 				di qualità schifosa.
-				Con i test che continuano a passare ti preoccupi di ri-arrangiare, cioè fare il
-				refactoring, del codice.
+				Assicurandoti che i test continuino a passare ti puoi preoccupare, allora, di ri-arrangiare 
+				il codice, cioè di fare il refactoring.
 				Questo ti garantisce di non compromettere le funzionalità.
 				Una volta che il codice è pulito quanto possibile sei pronto ad aggiungere
 				nuove funzionalità, ma non lo farai: aggiungerai, invece, un altro test
@@ -236,10 +236,10 @@
 				passare con successo i test che le definiscono.
             </p>
             <p>
-				Immagina il test come una specifica eseguibile che sia stata creata al momento.
+				Immagina il test come una specifica eseguibile che sia stata creata per l'occasione.
             </p>
             <p>
-				E' un approccio radicale e che personalmente mi sembra incompleto ma
+				E' un approccio radicale e personalmente mi sembra incompleto ma
 				è molto efficace per spiegare cosa sia uno unit tester.
 				Nel nostro caso abbiamo un test che fallisce (per non dire che va in crash)
 				così avremo bisogno di scrivere del codice in <em>log.php</em>:
@@ -256,7 +256,7 @@
 ?></strong>
 ]]></php>
 				Questo è il minimo da fare per evitare fatal error di PHP.
-				Adess recuperiamo il risultato:
+				Adesso recuperiamo il risultato:
                 <div class="demo">
                     <h1>TestOfLogging</h1>
                     <span class="fail">Fail</span>: testFirstLogMessagesCreatesFileIfNonexistent-&gt;True assertion failed.<br />
@@ -298,7 +298,7 @@
 				Questo è particolarmente vero nel caso si siano registrati fallimenti dei 
 				test e ci si voglia assicurare di non aver dimenticato qualcosa di
 				stupido.
-				Non procederemo così lentamente, così:
+				Non procederemo così lentamente, perciò:
 <php><![CDATA[
 <?php   
 class Log {<strong>
@@ -316,14 +316,13 @@
 }
 ?>
 ]]></php>
-				Ho avuto bisogno di non meno di quattro failure per arrivare al passo
-				successivo.
-				Non avevo creato la directory temporanea, non l'avevo impostata come
+				Ho dovuto incontrare non meno di quattro failure per raggiungere questo passo:
+				non avevo creato la directory temporanea, non l'avevo impostata come
 				pubblicamente accessibile in scrittura, avevo un errore di battitura e mi
 				ero dimenticato di aggiungere la nuova cartella sul CVS (questo l'ho scoperto più 
 				tardi).
 				Ognuno di questi problemi avrebbe potuto tenermi occupato per diverse ore
-				se solo si fossero manifestati in un secondo momento, ma è proprio per
+				se solo si fosse manifestato in un secondo momento, ma è proprio per
 				questo che i test servono.
                 
             </p>
@@ -338,14 +337,14 @@
             </p>
             <p>
 				Può darsi che tu non gradisca lo stile di visualizzazione minimale.
-				Di default, i successi nonn vengono mostrati perché generalmente non c'è
+				Di default, i successi non vengono mostrati perché, generalmente, non c'è
 				bisogno di ulteriori informazioni quando si ha la situazione
 				sotto controllo.
-				Se non si sa come le cose stanno procedento, allora è il caso di scrivere
+				Se non si sa come le cose stanno procedendo, allora è il caso di scrivere
 				ulteriori test.
             </p>
             <p>
-				Ok, questa è un po' una rigidità.
+				Ok, qui sono stato fin troppo rigido.
 				Se desideri vedere anche i casi di successo allora ti basta
 				<a local="display_subclass_tutorial">estendere la classe
                 <code>HtmlReporter</code></a>
@@ -353,9 +352,9 @@
 				Anche io gradisco il comfort, ogni tanto.
             </p>
         </section>
-        <section name="doc" title="Tests as Documentation">
+        <section name="doc" title="I test come documentazione">
             <p>
-				Adesso sottigliezza.
+				Adesso una sottigliezza.
                 Non vogliamo che il file creato esista fino a che non
 				inviamo il messaggio.
 				Piuttosto che pensarci troppo sopra, aggiungeremo
@@ -372,16 +371,16 @@
     }
 }
 ]]></php>
-                per scoprire che già funziona così
+                per scoprire che già funzionava così:
                 <div class="demo">
                     <h1>TestOfLogging</h1>
                     <div style="padding: 8px; margin-top: 1em; background-color: green; color: white;">1/1 test cases complete.
                     <strong>2</strong> passes, <strong>0</strong> fails and <strong>0</strong> exceptions.</div>
                 </div>
 				Ora, sapevo che avrebbe funzionato.
-				Ho aggiunto il test per confermarlo in parte per mettere in pace l'animo ma
-				anche per documentare questo comportamento.
-				Questa unica linea extra dice molto di più in questo contesto di dozzine
+				Ho aggiunto il test che lo conferma in parte per mettere in pace l'animo e in parte
+				per documentare questo comportamento.
+				Questa unica linea extra dice molto di più, in questo contesto, di dozzine
 				di righe di use case o di un intero diagramma di attività UML.
 				Che la test suite sia una sorgente di documentazione è un piacevole
 				effetto collaterale di tutti i test.

Modified: simpletest/trunk/docs/source/it/simple_test.xml
===================================================================
--- simpletest/trunk/docs/source/it/simple_test.xml	2009-09-29 14:06:36 UTC (rev 1957)
+++ simpletest/trunk/docs/source/it/simple_test.xml	2009-09-30 14:42:38 UTC (rev 1958)
@@ -19,24 +19,21 @@
 				di unit testing e la conoscenza del linguaggio di sviluppo PHP.
 				E' una guida pensata per i nuovi utenti di 
 				<a href="https://sourceforge.net/project/showfiles.php?group_id=76550">SimpleTest</a>
-				che si sentono impazienti di iniziare.
-				
-				Informazioni più approfondite, specialmente nel caso si sia inesperti di 
-				unit testing, possono essere reperite nella <a local="unit_test_documentation">documentazione</a>;
-				per gli esempi è possibile consultare il <a href="http://www.lastcraft.com/first_test_tutorial.php">tutorial</a>.
+				che si sentano particolarmente impazienti di iniziare.
+				Informazioni più approfondite, specialmente nel caso si sia completamento all'oscuro di
+				unit testing, possono essere reperite nella <a local="unit_test_documentation">documentazione</a> successiva;
+				case test di esempio possono essere trovati nel <a href="http://www.lastcraft.com/first_test_tutorial.php">tutorial</a>.
             </p>
         </introduction>
         <section name="unit" title="Iniziare subito ad utilizzare il tester">
             <p>
 			
-				Tra i tool di testing, uno unit tester è quello più vicino allo sviluppatore.
+				Tra i tool di collaudo lo unit tester è quello più vicino allo sviluppatore.
 				Nel contesto dello sviluppo agile, il codice di test si posiziona accanto 
 				al codice sorgente dal momento che entrambi vengono redatti nel medesimo momento. 
-				
 				In questa ottica, SimpleTest aspira ad essere una soluzione di test completa 
 				per lo sviluppatore PHP ed è chiamato "`Simple"' perché dovrebbe risultare 
-				semplice da utilizzare e da estendere. 
-				Non è stata una scelta di nome brillante, in effetti. 
+				semplice da utilizzare e da estendere (non è stata una scelta di nome così brillante, in effetti).
 				SimpleTest include tutte le classiche funzioni che ci si potrebbe aspettare 
 				da un porting di <a href="http://www.junit.org/">JUnit</a> e di 
 				<a href="http://sourceforge.net/projects/phpunit/">PHPUnit</a> ed include la gestione 
@@ -59,7 +56,7 @@
                 Il modo più rapido per dimostrare il funzionamento di SimpleTest è tramite un esempio.
             </p>
             <p>
-				Supponiamo di voler collaudare una semplice classe di logging su file chiamata 
+				Supponiamo di voler collaudare una semplice classe per il log su file chiamata 
 				<code>Log</code> e memorizzata in <em>classes/log.php</em>.
 				Iniziamo col creare uno script di test che chiameremo 
 				<em>tests/log_test.php</em>	e che popoleremo come segue:
@@ -87,7 +84,7 @@
 				è possibile avere quanti case test si desidera all'interno dello stesso file.
             </p>
             <p>
-				Con sole tre linee di scaffolding e l'inclusione della classe <code>Log</code>
+				Con sole tre linee per definire l'infrastruttura e per l'inclusione della classe <code>Log</code>
 				abbiamo ottenuto una suite di test. 
 				Tuttavia, non ci sono ancora test da eseguire.
                 
@@ -119,28 +116,28 @@
 				non inizi per &quot;test&quot; non è un test.
 
                 Si noti la lunghezza del nome <code>testLogCreatesNewFileOnFirstMessage()</code>:
-				l'uso di nomi lunghi è considerato un buono stile perché rende l'output 
+				l'uso di nomi lunghi è considerata una buona pratica perché rende l'output 
 				del test più leggibile.
             </p>
             <p>
-                Normalmente, si desidererà avere più metodi di test in un test case 
+                Normalmente si desidererà avere più di un test test in un test case 
 				ma parleremo di questo in seguito.
             </p>
             <p>
-				Le assertion all'interno dei metodi di test scatenano dei 
+				Le assertion all'interno dei metodi di test generano dei 
 				messaggi indirizzati al framework il quale mostra immediatamente 
 				a schermo il risultato.
 				
 				Il fatto che la risposta sia immediata 
 				è importante non soltanto nel caso in cui il codice generi 
-				un crash ma anche perché, in questo modo, <code>print</code> 
-				può visualizzare il contenuto di debug accanto 
+				un crash ma anche perché, in questo modo, le funzioni di stampa
+				possono visualizzare il contenuto di debug accanto 
 				al messaggio di assertion interessato.
 		
             </p>
             <p>
 			
-				Per visualizzare il risultati non si dovrà che eseguire i test.
+				Per visualizzare il risultato non si dovrà far altro che eseguire il test.
 				Non è necessario altro codice: è sufficiente aprire la pagina 
 				con un browser.
             </p>
@@ -176,19 +173,19 @@
 ?>
 ]]></php>
 
-				Scrivere il codice \emph{dopo} aver scritto il test è divertente.
+				Scrivere il codice <em>dopo</em> aver scritto il test è divertente.
 				Molto più che divertente: questo sistema si chiama &quot;Test Driven Development&quot;.
             </p>
             <p>
 			
 				Per maggiori informazioni su <code>UnitTestCase</code>,
-				si veda la documentazione su <a local="unit_test_documentation">unit test</a>.
+				si veda la documentazione sugli <a href="unit_test_documentation.php">unit test</a>.
             </p>
         </section>
         <section name="group" title="Raggruppare i test">
             <p>
-				E' improbabile che in un'applicazione reale venga avviato un solo case test.
-				Questo implica che debba esistere un sistema per raggruppare i case in 
+				E' improbabile che in un'applicazione reale venga avviato un solo case test e per questo
+				deve esistere un sistema per raggruppare i case in 
 				test script che, all'occorrenza, eseguano più test per l'intera applicazione.
             </p>
             <p>
@@ -206,23 +203,23 @@
 }
 ?>
 ]]></php>
-				L'inclusione di &quot;autorun&quot; permette di eseguire, 
+				L'inclusione di &quot;autorun.php&quot; permette di eseguire, 
 				con l'invocazione di questo script, anche gli eventuali test 
 				aggiunti in futuro.
             </p>
-            <p>
+            <!--<p>
 				Le sottoclassi di <code>TestSuite</code> devono invocare il 
 				costruttore di TestSuite: questa limitazione verrà rimossa nelle
 				versioni future.
-            </p>
+            </p>-->
             <p>
 				Il metodo <code>TestSuite::addFile()</code> 
-				include il test case specificato e legge tutte 
-				le nuove classi che ereditano <code>SimpleTestCase</code>.
+				include il test case specificato e vi recupera tutte 
+				le nuove classi discendenti da <code>SimpleTestCase</code>.
 				<code>UnitTestCase</code> è solo un esempio di classe derivata 
 				da <code>SimpleTestCase</code> ed è possibile, naturalmente, 
 				crearne altre a piacimento. <code>TestSuite::addFile()</code>
-				può essere usato per includere le altre test suite.
+				può essere usato anche per includere altre test suite.
 
             </p>
             <p>
@@ -239,12 +236,12 @@
 			
 				E' consetuidine raggruppare il codice dei case test in superclassi 
 				la cui esecuzione diretta non è prevista ma che vengono utilizzate 
-				come classi base di altri test. Affinché \texttt{autorun} 
+				come classi base di altri test. Affinché <code>autorun</code> 
 				funzioni propriamente un test case non dovrebbe ciecamente 
 				eseguire alcun altra "`test case extensions"' che non esegua 
 				effettivamente alcun test. Questo, infatti, potrebbe essere conteggiato, 
-				durante l'esecuzione, come un test case extra eseguito. 
-				E' raro che questo rappresenti un problema, ma per evitare 
+				durante l'esecuzione, come un test eseguito. 
+				E' raro che questo rappresenti un problema ma per evitare 
 				l'inconveniente è sufficiente marcare la classe base 
 				come <code>abstract</code>. 
 				SimpleTest non esegue classi abstract. 
@@ -279,9 +276,9 @@
                 Facciamo un salto nel futuro ed affrontiamo qualcosa di davvero complesso.
             </p>
             <p>
-				Assumiamo che la nostra classe di logging sia stata 
+				Assumiamo che la nostra classe per il log sia stata 
 				collaudata e completata. Supponiamo anche che si stia 
-				testando un'altra classe a cui sia richiesto di 
+				collaudando un'altra classe a cui sia richiesto di 
 				scrivere dei messaggi di log, per esempio <code>SessionPool</code>. 
 				Vogliamo collaudare un metodo che avrà probabilmente un codice simile a:
 
@@ -331,7 +328,7 @@
 
             </p>
             <p>
-				Il design di questo case test non è completamente sbagliato, 
+				Il design di questo case test non è completamente sbagliato
 				ma potremmo provare a migliorarlo. Stiamo spendendo 
 				tempo gingillandoci con i file di log quando questo 
 				non sarebbe competenza di questo test. Quel che è successo 
@@ -340,7 +337,7 @@
 				decidesse di non usare più i file ed usare al loro posto 
 				la libreria <em>syslog</em>? Accadrebbe che 
 				<code>TestOfSessionLogging</code> fallirebbe sempre, 
-				anche se non starebbe testando Logging.
+				anche se la sua funzione non sarebbe quella di collaudare Log.
 
             </p>
             <p>
@@ -354,8 +351,8 @@
             <p>
 				La sola cosa che desideriamo davvero collaudare è 
 				che un particolare messaggio venga veramente inviato
-				al logger. Possiamo ridurre l'accoppiamento tra le 
-				due classi se passiamo una falsa classe di logging 
+				al logger. Potremmo ridurre l'accoppiamento tra le 
+				due classi passando una falsa classe di logging 
 				che accetti le richieste di registrazione di messaggi 
 				per i test ma non esegua alcuna azione. 
 				Tuttavia, dovrebbe avere lo stesso identico aspetto 
@@ -394,7 +391,7 @@
 ]]></php>
 				Con l'invocazione di <code>Mock::generate()</code> viene generata 
 				una nuova classe chiamata <code>MockLog</code>. Questa classe 
-				appare come un clone della classe originale, con la differenza che 
+				appare come un clone della classe originale con la differenza che 
 				ci permette di cablarvi dentro del codice di test. 
 				E' quello che <code>expectOnce()</code> fa: specifica che 
 				se il metodo <code>message()</code> dovesse essere chiamato, 
@@ -408,7 +405,7 @@
 				sull'oggetto <code>MockLog</code>. La chiamata al Mock 
 				scatenerà una comparazione tra i parametri e restituirà 
 				un evento di successo o di fallimento al display del test. 
-				E' anche possibile utilizzare dei wildcard, 
+				E' anche possibile utilizzare dei carateri jolly, 
 				così non sarà necessario collaudare ogni singolo parametro 
 				di una chiamata se se ne vuole collaudare solo uno.
 
@@ -431,7 +428,7 @@
             </p>
             <p>
 				Per ulteriori informazioni su mocking e stubbing si veda la 
-				<a local="mock_objects_documentation">mock objects documentation</a>.
+				<a href="mock_objects_documentation.php">documentazione sugli oggetti mock</a>.
             </p>
         </section>
         <section name="web" title="Il collaudo di pagine web">
@@ -443,7 +440,7 @@
 				e verificare la correttezza dell'output. Questo lavoro è svolto dal web tester.
             </p>
             <p>
-				Il web testing in SimpleTest è abbastanza primitivo, 
+				Il collaudo web in SimpleTest è abbastanza primitivo
 				dal momento che non suppporta JavaScript. 
 				La maggior parte delle altre operazioni del browser sono implementate.
                 
@@ -467,8 +464,8 @@
 }
 ?>
 ]]></php>
-				Con questo codice come acceptance test, si può garantire che il contenuto 
-				aderisca sempre alle specifiche degli sviluppatore e 
+				Con questo codice come acceptance test si può garantire che il contenuto 
+				aderisca sempre alle specifiche degli sviluppatori e 
 				degli altri stakeholder del progetto.
                 
             </p>
@@ -494,8 +491,8 @@
             <p>
                 
 				Per ulteriori informazioni sul web testing, si veda la 
-				<a local="browser_documentation">scriptable browser documentation</a> 
-				e la documentazione su <a local="web_tester_documentation">WebTestCase</a>.
+				<a href="browser_documentation.php">scriptable browser documentation</a> 
+				e la documentazione su <a href="web_tester_documentation.php">WebTestCase</a>.
             </p>
             <p>
                 <a href="http://sourceforge.net/projects/simpletest/"><img src="http://sourceforge.net/sflogo.php?group_id=76550&amp;type=5" width="210" height="62" border="0" alt="SourceForge.net Logo"/></a>


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 1949
          http://simpletest.svn.sourceforge.net/simpletest/?rev=1949&view=rev
Author:   arialdomartini
Date:     2009-09-08 13:20:51 +0000 (Tue, 08 Sep 2009)

Log Message:
-----------
3 pages translated from English to Italian.
Minor fixes in English version:
implemntation => implementation
afterwoods => afterwards

Modified Paths:
--------------
    simpletest/trunk/docs/source/en/mock_objects_documentation.xml
    simpletest/trunk/docs/source/it/group_test_documentation.xml
    simpletest/trunk/docs/source/it/mock_objects_documentation.xml
    simpletest/trunk/docs/source/it/unit_test_documentation.xml

Modified: simpletest/trunk/docs/source/en/mock_objects_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/en/mock_objects_documentation.xml	2009-09-06 18:07:34 UTC (rev 1948)
+++ simpletest/trunk/docs/source/en/mock_objects_documentation.xml	2009-09-08 13:20:51 UTC (rev 1949)
@@ -433,7 +433,7 @@
             </p>
             <p>
                 Objects with dynamic interfaces, using <code>__call</code>, can
-                be problematic with the current mock objects implemntation.
+                be problematic with the current mock objects implementation.
                 You can mock the <code>__call()</code> method, but this is ugly.
                 Why should a test know anything about such low level implementation details?
                 It just wants to simulate the call.
@@ -571,8 +571,8 @@
             <p>
                 Tests without assertions can be both compact and very expressive.
                 Because we intercept the call on the way into an object, here of
-                the <code>Alert</code> class, we avoid having to assert it's state
-                afterwoods.
+                the <code>Alert</code> class, we avoid having to assert its state
+                afterwards.
                 This not only avoids the assertions in the tests, but also having
                 to add extra test only accessors to the original code.
                 If you catch yourself adding such accessors, called &quot;state based testing&quot;,

Modified: simpletest/trunk/docs/source/it/group_test_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/group_test_documentation.xml	2009-09-06 18:07:34 UTC (rev 1948)
+++ simpletest/trunk/docs/source/it/group_test_documentation.xml	2009-09-08 13:20:51 UTC (rev 1949)
@@ -5,8 +5,8 @@
     <content>
         <section name="group" title="Grouping tests into suites">
             <p>
-                There are many ways to group tests together into test suites.
-                One way is to simply place multiple test cases into a single file...
+				Eistono molti sistemi per raggruppare i test in test suite.
+				Uno di questi \xE8 quello di mettere semplicemente pi\xF9 test case in un singolo file:
 <php><![CDATA[
 <strong><?php
 require_once(dirname(__FILE__) . '/simpletest/autorun.php');
@@ -21,13 +21,15 @@
 }
 ?></strong>
 ]]></php>
-                As many cases as needed can appear in a single file.
-                They should include any code they need, such as the library
-                being tested, but need none of the SimpleTest libraries.
+				E' possibile mettere quanti test case si vuole in ogni file.
+				Ogni file necessario all'esecuzione, come ad esempio la libreria da
+				collaudare, dovrebbe essere incluso ma non \xE8 necessario includere
+				alcuna libreria di SimpleTest.
             </p>
             <p>
-                If you have extended any test cases, you can include them too.
-                Simply mark any test cases that should not be run as abstract...
+				Nel caso si sia estesa qualche test case da una classe base, anche questa
+				deve essere inclusa.
+                Qualsiasi classe di test non debba essere invocata deve essere marcata come abstract:
 <php><![CDATA[
 <strong>abstract</strong> class MyFileTestCase extends UnitTestCase {
     ...
@@ -37,17 +39,17 @@
 
 class SocketTester extends UnitTestCase { ... }
 ]]></php>
-                Here the <code>FileTester</code> class does
-                not contain any actual tests, but is a base class for other
-                test cases.
+				Qui, ad esempio, la classe <code>FileTester</code> non contiene
+				alcun test ma viene utilizzata come classe base per altri case test.
             </p>
             <p>
-                We will call this sample <em>file_test.php</em>.
-                Next we create a test suite file, called say <em>my_test_suite.php</em>.
-                You will think of a better name I am sure.
+				Chiameremo questo file di esempio <em>file_test.php</em>.
+				Il passo successivo \xE8 quello di creare il file della test suite
+				che potremmo chiamare <em>my_test_suite.php</em>.
+                Sono certo che saprai trovare nomi migliori di questo.
             </p>
             <p>
-                We will add the test file using a safe method...
+				Adesso aggiungeremo il test file alla suite con un metodo sicuro:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -61,18 +63,17 @@
 }
 ?>
 ]]></php>
-                What happens here is that the <code>TestSuite</code>
-                class will do the <code>require_once()</code>
-                for us.
-                It then checks to see if any new test case classes
-                have been created by the new file and automatically adds
-                them to the test suite.
-                This method gives us the most control.
+				Quello che accadr\xE0 \xE8 che la classe <code>TestSuite</code>
+				penser\xE0 autonomamente ad eseguire i <code>require_once()</code>
+				necessari, controller\xE0 se nuove classi di test case sono presenti nel
+				file e all'occorrenza li aggiunger\xE0 alla test suite.
+				
+                Questo metodo ci fornisce il massimo del controllo.
             </p>
             <p>
-                If this is too much typing, and you are willing to group
-                test suites together in their own directories or otherwise
-                tag the file names, then there is a more automatic way...
+				Nel caso questo metodo sembrasse troppo prolisso e si desiderasse
+				di raggruppare tra loro pi\xF9 test suite di una stessa directory oppure in
+				base al loro nome del file, esiste un metodo ancora pi\xF9 automatico:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -86,36 +87,35 @@
 }
 ?>
 ]]></php>
-                This will scan a directory called &quot;unit&quot; for any files
-                ending with &quot;_test.php&quot; and load them.
-                You don&apos;t have to use <code>SimplePatternCollector</code> to
-                filter by a pattern in the filename, but this is the most common
-                usage.
+				Questo sistema ricerca nella directory &quot;unit&quot; i file
+				il cui nome termina per &quot;_test.php&quot; e li carica.
+				L'uso di <code>SimplePatternCollector</code> per filtrare in
+				base ad un pattern non \xE8 obbligatorio ma \xE8 il sistema pi\xF9 comune.
             </p>
             <p>
-                Now all you have to do is drop a file of test cases into the
-                directory and it will run just by running the test suite script.
+				Tutto quel che resta da fare adesso \xE8 creare un file nella directory 
+				dei test case che lancer\xE0 lo script della test suite.
             </p>
             <p>
-                Test cases loaded with the <code>addFile</code> method have some
-                useful properties.
-                You can guarantee that the constructor is run
-                just before the first test method and the destructor
-                is run just after the last test method.
-                This allows you to place test case wide set up and tear down
-                code in the constructor and destructor, just like a normal
-                class.
+				I test case caricati con il metodo <code>addFile</code> posseggono
+				alcune utili propriet\xE0.
+				Si ha la certezza che il costruttore sia invocato prima del lancio del
+				primo test e il distruttore dopo l'esecuzione dell'ultimo.
+				Questo consente di ospitare nel costruttore e nel distruttore
+				il codice di set up e di tear down che deve valere per tutto il test case.
             </p>
         </section>
         <section name="higher" title="Composite suites">
             <p>
-                The above method places all of the test cases into one large suite.
-                For larger projects though this may not be flexible enough; you
-                may want to group the tests in all sorts of ways.
+				Il metodo appena presentato prevede di ospitare tutti i test case in
+				un'unica grande test suite.
+				Per progetti di grandi dimensione, tuttavia, questo metodo non risulta
+				abbastanza flessibile perch\xE9 si potrebbe desiderare di raggrupare 
+				test nelle pi\xF9 varie modalit\xE0.
             </p>
             <p>
-                To get a more flexible group test we can subclass
-                <code>TestSuite</code> and then instantiate it as needed...
+				Per poter disporre di un group test pi\xF9 flessibile
+				\xE8 possibile istanziare una classe che erediti da <code>TestSuite</code>:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -128,11 +128,11 @@
 }</strong>
 ?>
 ]]></php>
-                This effectively adds our test cases and a single suite below
-                the first.
-                Not much use as is, but we can add more than one suite at this point.
-                We can even mix groups and test cases freely as long as
-                we are careful about double includes.
+				In questo modo si \xE8 aggiunta una test suite dentro un'altra.
+				In questo caso non risulta molto utile ma \xE8 possibile aggiungere
+				altre suite a piacimento.
+				E' perfino possibile mescolare gruppi e singoli test case a patto
+				di prestare attenzione alle inclusioni multiple.
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -146,8 +146,8 @@
 }
 ?>
 ]]></php>
-                In the event of a double include, ony the first instance
-                of the test case will be run.
+                Nel caso si includa un file pi\xF9 di una volta, verrebbe eseguita
+				solo la prima istanza del test.
             </p>
         </section>
     </content>

Modified: simpletest/trunk/docs/source/it/mock_objects_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/mock_objects_documentation.xml	2009-09-06 18:07:34 UTC (rev 1948)
+++ simpletest/trunk/docs/source/it/mock_objects_documentation.xml	2009-09-08 13:20:51 UTC (rev 1949)
@@ -5,58 +5,68 @@
     <content>
         <section name="what" title="What are mock objects?">
             <p>
-                Mock objects have two roles during a test case: actor and critic.
+				Gli oggetti mock svolgono due ruoli durante un test case: il ruolo di "attori"
+				ed il ruolo di "critici"
             </p>
             <p>
-                The actor behaviour is to simulate objects that are difficult to
-                set up or time consuming to set up for a test.
-                The classic example is a database connection.
-                Setting up a test database at the start of each test would slow
-                testing to a crawl and would require the installation of the
-                database engine and test data on the test machine.
-                If we can simulate the connection and return data of our
-                choosing we not only win on the pragmatics of testing, but can
-                also feed our code spurious data to see how it responds.
-                We can simulate databases being down or other extremes
-                without having to create a broken database for real.
-                In other words, we get greater control of the test environment.
+                Nel ruolo di attore il mock ha la funzione di simulare il
+				comportamento di un altro oggetto che durante il test sarebbe
+				difficile o oneroso da instanziare.
+				L'esempio classico \xE8 quello di una connessione ad un database.
+				Allestire un database di collaudo all'inizio di ogni singolo testo
+				rallenterebbe il collaudo a livelli inaccettabile e richiederebbe
+				l'istallazione di un apposito motore di database e di dati di test sul
+				server di test.
+                Se ci fosse la possibilit\xE0 di similare la connessione e restituire
+				i dati selezionati per il collaudo non solo si otterrebbero dei
+				test pi\xF9 pragmatici ma ci si potrebbe permettere di alimentare il
+				codice con dati spuri per vederne la reazione.
+				Avremmo la possibilit\xE0 di simulare il caso di un database fuori linea o
+				altre condizioni estreme di questo tipo, senza la necessit\xE0 di generare
+				i malfunzionamenti nella realt\xE0.
+				In altre parole, i mock possono fornire un grande controllo dell'ambiente
+				di test.
             </p>
             <p>
-                If mock objects only behaved as actors they would simply be
-                known as &quot;server stubs&quot;.
-                This was originally a pattern named by Robert Binder (<a href="">Testing
-                object-oriented systems</a>: models, patterns, and tools,
-                Addison-Wesley) in 1999.
+				Se gli oggetti mock si comportassero solo come attori sarebbero
+				semplicemente conosciuto come &quot;server stubs&quot;.
+                Questi sono stati introdotti come pattern di sviluppo da  
+				Robert Binder in (<a href="">Testing object-oriented systems</a> models, patterns, and tools,
+                Addison-Wesley) nel 1999.
             </p>
             <p>
-                A server stub is a simulation of an object or component.
-                It should exactly replace a component in a system for test
-                or prototyping purposes, but remain lightweight.
-                This allows tests to run more quickly, or if the simulated
-                class has not been written, to run at all.
+				Un server stub \xE8 la simulazione di un oggetto o di un componente.
+				Dovrebbe rimpiazzare esplicitamente un componente con lo scopo di
+				permettere il test o la prototipazione ma, fondamentalmente, resta un
+				componente leggero.
+				In questo modo permette ai test di eseguirsi con rapidit\xE0; nel caso
+				la classe simulata ancora non esista affatto, permettono di eseguire
+				comunque il codice.
             </p>
             <p>
-                However, the mock objects not only play a part (by supplying chosen
-                return values on demand) they are also sensitive to the
-                messages sent to them (via expectations).
-                By setting expected parameters for a method call they act
-                as a guard that the calls upon them are made correctly.
-                If expectations are not met they save us the effort of
-                writing a failed test assertion by performing that duty on our
-                behalf.
+				Tuttavia, gli oggetti mock non solo svolgono questo ruolo
+				(restituiendo valori di ritorno alla loro interrogazione) ma
+				sono anche sensibili ai messaggi che vengono loro inviati
+				(tramite le expectation).
+				Impostando i parametri attesi dalla invocazione di un metodo
+				i mock si comportano da garanti della correttezza nelle chiamate
+				ai metodi.
+				Se le expectation non sono rispettare, i mock ci risparmiano la
+				fatica di scrivere le assert fanno il lavoro sporco a posto nostro.
             </p>
             <p>
-                In the case of an imaginary database connection they can
-                test that the query, say SQL, was correctly formed by
-                the object that is using the connection.
-                Set them up with fairly tight expectations and you will
-                hardly need manual assertions at all.
+                Nel caso della connessione ad un database immaginrio sono
+				in grado di verificare l'oggetto chiamante stia usando una query, supponiamo
+				SQL, formalmente corretta.
+				Una volta preparai con expectation sufficientemente rigorose
+				non si avr\xE0 pi\xF9 bisogno di eseguire manualmente gli assert.
             </p>
         </section>
         <section name="creation" title="Creating mock objects">
             <p>
-                All we need is an existing class, say a database connection
-                that looks like this...
+				Tutto quello di cui abbiamo bisogno \xE8 una classe esistente,
+				supponiamo per la connessione al database, che abbia
+				questo aspetto:
 <php><![CDATA[
 <strong>class DatabaseConnection {
     function DatabaseConnection() { }
@@ -64,8 +74,8 @@
     function selectQuery($sql) { }
 }</strong>
 ]]></php>
-                The class does not need to have been implemented yet.
-                It could be just an interface...
+				Non c'\xE8 bisogno che la classe sia stata implementata.
+				Pu\xF2 bastare la sua interfaccia:
 <php><![CDATA[
 <strong>interface DatabaseConnection {
     function DatabaseConnection();
@@ -73,18 +83,18 @@
     function selectQuery($sql);
 }</strong>
 ]]></php>
-                To create a mock version of the class we need to run a
-                code generator...
+				Per generare una versione mock della classe si
+				deve invocare il code generator:
 <php><![CDATA[
 require_once('simpletest/autorun.php');
 require_once('database_connection.php');
 
 <strong>Mock::generate('DatabaseConnection');</strong>
 ]]></php>
-                This generates a clone class called
-                <code>MockDatabaseConnection</code>.
-                We can now create instances of the new class within
-                our test case...
+				Questo genera una classe clone
+				chiamata <code>MockDatabaseConnection</code>.
+				Adesso \xE8 possibile istanziare la nuova classe
+				all'interno del test case:
 <php><![CDATA[
 require_once('simpletest/autorun.php');
 require_once('database_connection.php');
@@ -98,9 +108,9 @@
     }
 }
 ]]></php>
-                The mock version now has all the methods of the original.
-                Also, any type hints will be faithfully preserved.
-                Say our query methods expect a <code>Query</code> object...
+				La versione mock possiede tutti i metodi della classe originale.
+                Anche i tipi degli argomenti vengono fedelmente preservati.
+                Supponiamo che il metodo query si aspetti un oggetto <code>Query</code>:
 <php><![CDATA[
 <strong>class DatabaseConnection {
     function DatabaseConnection() { }
@@ -108,7 +118,8 @@
     function selectQuery(Query $query) { }
 }</strong>
 ]]></php>
-                If we now pass the wrong type of object, or worse a non-object...
+				Nel caso si invochi il metodo con un oggetto di tipo sbagliato o,
+				peggio, con un non-object...
 <php><![CDATA[
 class MyTestCase extends UnitTestCase {
 
@@ -118,54 +129,57 @@
     }
 }
 ]]></php>
-                ...the code will throw a type violation at you just as the
-                original class would.
+                ...il codice lancerebbe un'eccezione di violazione di tipo
+				esattamente come farebbe la classe originale.
             </p>
             <p>
-                The mock version now has all the methods of the original.
-                Unfortunately, they all return <code>null</code>.
-                As methods that always return <code>null</code> are not that useful,
-                we need to be able to set them to something else...
+				Anche se la versione mock possiede tutti i metodi della classe originale,
+				questi restituiscono sfortunatamente <code>null</code>.
+				Dal momenti che i metodi restituiscono sistematicamente <code>null</code>
+				non risultano molto utili
+				ed abbiamo bisogno di un modo per impostarle per
+				avere un comportamento diverso:
             </p>
             <p>
                 <a class="target" name="stub"><h2>Mocks as actors</h2></a>
             </p>
             <p>
-                Changing the return value of a method from <code>null</code>
-                to something else is pretty easy...
+                Modificare il valore di ritorno di un metodo da <code>null</code>
+				a qualcos'altro \xE8 abbastanza semplice:
 <php><![CDATA[
 <strong>$connection->returns('query', 37)</strong>
 ]]></php>
-                Now every time we call
-                <code><![CDATA[$connection->query()]]></code> we get
-                the result of 37.
-                There is nothing special about 37.
-                The return value can be arbitrarily complicated.
+                Adesso, ogni invocazione di
+                <code><![CDATA[$connection->query()]]></code> restituisce 37.
+                38 non ha niente di speciale: il valore di ritorno pu\xF2
+				essere arbitrariamente complesso.
             </p>
             <p>
-                Parameters are irrelevant here, we always get the same
-                values back each time once they have been set up this way.
-                That may not sound like a convincing replica of a
-                database connection, but for the half a dozen lines of
-                a test method it is usually all you need.
+				I parametri, in questo caso, sono irrilevanti e 
+				una volta che si sia impostato il mock con questo
+				sistema si otterr\xE0 sempre il medesimo valore qualsiasi essi siano
+                Questa potrebbe apparire una replica poco convincente di una
+				connessione al database, ma per un metodo di test di
+				una mezza dozzina di righe, solitamente, \xE8 tutto quello
+				di cui si pu\xF2 aver bisogno.
             </p>
             <p>
-                Things aren&apos;t always that simple though.
-                One common problem is iterators, where constantly returning
-                the same value could cause an endless loop in the object
-                being tested.
-                For these we need to set up sequences of values.
-                Let&apos;s say we have a simple iterator that looks like this...
+				Tuttavia, le cose non sono sempre cos\xEC semplici.
+				Uno dei problemi comuni si propone con le iterazioni, nelle quali
+				il ritorno sistematico del solito valore pu\xF2 causare cicli
+				infiniti dentro l'oggetto da collaudare.
+				Per questo c'\xE8 bisogno di poter impostare sequenze di valori.
+				Supponiamo di avere una semplice iterazione come questa:
 <php><![CDATA[
 class Iterator {
     function Iterator() { }
     function next() { }
 }
 ]]></php>
-                This is about the simplest iterator you could have.
-                Assuming that this iterator only returns text until it
-                reaches the end, when it returns false, we can simulate it
-                with...
+				Stiamo parlando dell'iterazione pi\xF9 semplice che possa capitare.
+				Se si assume che questa iterazione restituisca del testo
+				fino a quando raggiunge la fine e che da quel momento
+				debba restituire false, si potrebbe simularla cos\xEC:
 <php><![CDATA[
 Mock::generate('Iterator');
 
@@ -180,90 +194,93 @@
     }
 }
 ]]></php>
-                When <code>next()</code> is called on the
-                <code>MockIterator</code> it will first return &quot;First string&quot;,
-                on the second call &quot;Second string&quot; will be returned
-                and on any other call <code>false</code> will
-                be returned.
-                The sequenced return values take precedence over the constant
-                return value.
-                The constant one is a kind of default if you like.
+				Quando <code>next()</code> di <code>MockIterator</code> viene invocata
+				restituir\xE0 &quot;First string&quot; la prima volta e &quot;Second string&quot; la
+				seconda mentre false tutte le altre volte.
+				I valori di ritorno delle sequenze hanno precedenza sul valori
+				di ritorno costante.
+				Se pu\xF2 essere utile, si pu\xF2 pensare al valore di ritorno costante
+				come il valore di ritorno di default.
             </p>
             <p>
-                Another tricky situation is an overloaded
-                <code>get()</code> operation.
-                An example of this is an information holder with name/value pairs.
-                Say we have a configuration class like...
+				Un'altra situazione delicata \xE8 il caso di un'operazione 
+                <code>get()</code> overloaded.
+				Ad esempio \xE8 quando un'informazione conservata con una coppia nome/valore.
+				Supponiamo di avere una classe di configurazione come questa:
 <php><![CDATA[
 class Configuration {
     function Configuration() { ... }
     function get($key) { ... }
 }
 ]]></php>
-                This is a likely situation for using mock objects, as
-                actual configuration will vary from machine to machine and
-                even from test to test.
-                The problem though is that all the data comes through the
-                <code>get()</code> method and yet
-                we want different results for different keys.
-                Luckily the mocks have a filter system...
+				Questo \xE8 la tipica situazione in cui un oggetto mock risulta
+				utile, dal momento che la configurazione variet\xE0 da macchina
+				a macchina e perfino da test a test.
+				Tuttavia, il problema \xE8 che i dati vengono recuperati mediante
+				la chiamata al metodo <code>get()</code> e che, contemporaneamente,
+				si desiderano valori differenti in corrispondenza di chiavi differenti.
+				Fortunatamente, i mock dispongono di un sistema di filtraggio:
 <php><![CDATA[
 <strong>$config = &new MockConfiguration();
 $config->returns('get', 'primary', array('db_host'));
 $config->returns('get', 'admin', array('db_user'));
 $config->returns('get', 'secret', array('db_password'));</strong>
 ]]></php>
-                The extra parameter is a list of arguments to attempt
-                to match.
-                In this case we are trying to match only one argument which
-                is the look up key.
-                Now when the mock object has the
-                <code>get()</code> method invoked
-                like this...
+				Il parametro aggiunto \xE8 l'elenco degli argomenti con
+				i quali provare a fare un match.
+				In questo caso, ad esempio, si sta provando il match con il solo
+				argomento a disposizione il quale viene usato come look up key.
+				Adesso, quando il metodo <code>get()</code> dell'oggetto mock
+				viene invocato, come in...
 <php><![CDATA[
 $config->get('db_user')
 ]]></php>
-                ...it will return &quot;admin&quot;.
-                It finds this by attempting to match the calling arguments
-                to its list of returns one after another until
-                a complete match is found.
+                ...restituir\xE0 &quot;admin&quot;.
+				Il risultato \xE8 stato ricavato tentando il match degli argomenti
+				richiesti con ognuno dei valori dell'elenco, fino a che un match
+				completo viene individuato.
             </p>
             <p>
-                You can set a default argument argument like so...
+				E' anche possibile impostare un argomento di default:
 <php><![CDATA[<strong>
 $config->returns('get', false, array('*'));</strong>
 ]]></php>
-                This is not the same as setting the return value without
-                any argument requirements like this...
+				Questo non \xE8 equivalente ad impostare il valore di
+				ritorno che si deve avere in assenza di argomenti, come accade con:
 <php><![CDATA[<strong>
 $config->returns('get', false);</strong>
 ]]></php>
-                In the first case it will accept any single argument,
-                but exactly one is required.
-                In the second case any number of arguments will do and
-                it acts as a catchall after all other matches.
-                Note that if we add further single parameter options after
-                the wildcard in the first case, they will be ignored as the wildcard
-                will match first.
-                With complex parameter lists the ordering could be important
-                or else desired matches could be masked by earlier wildcard
-                ones.
-                Declare the most specific matches first if you are not sure.
+				Nel primo caso, viene accettato qualsiasi singolo argomento ma
+				un argomento \xE8 comunque richiesto.
+                Il secondo caso accetta un qualsiasi numero di argomenti e
+				viene considerato nel caso siano gi\xE0 stati tentati tutti gli altri match.
+				
+				Si noti che se nel primo caso si aggiungesse ulteriori parametri
+				dopo il carattere jolly questi verrebbero ignorati perch\xE9 
+				la condizione sul carattere jolly verrebbe soddisfatta prima della
+				loro valutazione.
+				
+				Con elenchi di parametri particolarmente complessi l'ordine
+				potrebbe essere importante e si corre il rischio di avere delle
+				corrispondenze che vengono mascherate da caretteri jolly dichiarati
+				prima.
+				Nel caso di dubbi \xE8 meglio dichiarare i match pi\xF9 specifici all'inzio.
+
             </p>
             <p>
-                There are times when you want a specific reference to be
-                dished out by the mock rather than a copy or object handle.
-                This a rarity to say the least, but you might be simulating
-                a container that can hold primitives such as strings.
-                For example...
+				Ci sono casi in cui si desidera che il mock gestisca dei
+				riferimenti ad oggetti piuttosto che delle copie degli stessi.
+				Accade raramente, ma potrebbe capitare di dover simulare
+				un oggetto che gestisce dati primitivi, come delle stringhe.
+				Per esempio:
 <php><![CDATA[
 class Pad {
     function Pad() { }
     function &note($index) { }
 }
 ]]></php>
-                In this case you can set a reference into the mock&apos;s
-                return list...
+                In questo caso, per impostare un riferimento nell'elenco
+				dei valori di ritorno:
 <php><![CDATA[
 function testTaskReads() {
     $note = 'Buy books';
@@ -273,15 +290,15 @@
     ...
 }
 ]]></php>
-                With this arrangement you know that every time
-                <code><![CDATA[$pad->note(3)]]></code> is
-                called it will return the same <code>$note</code> each time,
-                even if it get's modified.
+				Con questa soluzione si \xE8 certi che ogni volta che viene
+				invocato  <code><![CDATA[$pad->note(3)]]></code> viene
+				restituito sempre il medesimo oggetto <code>$note</code>, perfino
+				quando questo viene modificato.
             </p>
             <p>
-                These three factors, timing, parameters and whether to copy,
-                can be combined orthogonally.
-                For example...
+				E' possibile combinare ortogonalmente i tre fattori tempo, parametri e
+				uso delle copie e dei riferimenti. Per esempio:
+                
 <php><![CDATA[
 $buy_books = 'Buy books';
 $write_code = 'Write code';
@@ -289,20 +306,20 @@
 $vector-><strong>returnsByReferenceAt(0, 'note', $buy_books, array('*', 3));
 $vector-><strong>returnsByReferenceAt(1, 'note', $write_code, array('*', 3));
 ]]></php>
-                This will return a reference to <code>$buy_books</code> and
-                then to <code>$write_code</code>, but only if two parameters
-                were set the second of which must be the integer 3.
-                That should cover most situations.
+				Questo restituisce un riferimento a <code>$buy_books</code> e
+				successivamente a <code>$write_code</code>, ma solo sei i due
+				paramtri risultano impostati ed il secondo \xE8 l'intero 3.
+				In questo modo ogni esigenza dovrebbe risultare soddisfatta.
             </p>
             <p>
-                A final tricky case is one object creating another, known
-                as a factory pattern.
-                Suppose that on a successful query to our imaginary
-                database, a result set is returned as an iterator, with
-                each call to the the iterator&apos;s <code>next()</code> giving
-                one row until false.
-                This sounds like a simulation nightmare, but in fact it can all
-                be mocked using the mechanics above...
+				Un ultimo caso delicato \xE8 quello di un oggetto che ne instanzia un
+				altro, ovvero quello che \xE8 conosciuto come factory pattern.
+                Supponiamo che una query al nostro immaginario database abbia successo
+				e che venga restituito un result set nella forma di iteratore in modo
+				che ad ogni chiamata del metodo <code>next()</code> dell'iteratore venga fornita una
+				riga o il valore false.
+				L'idea di dover simulare un comportamento simile pu\xF2 sembrare da incubo ma
+				in realt\xE0 pu\xF2 essere realizzata con un mock con il meccanismi gi\xE0 presentati:
 <php><![CDATA[
 Mock::generate('DatabaseConnection');
 Mock::generate('ResultIterator');
@@ -326,46 +343,44 @@
     }
 }
 ]]></php>
-                Now only if our
-                <code>$connection</code> is called with the
-                <code>query()</code> method will the
-                <code>$result</code> be returned that is
-                itself exhausted after the third call to <code>next()</code>.
-                This should be enough
-                information for our <code>UserFinder</code> class,
-                the class actually
-                being tested here, to come up with goods.
-                A very precise test and not a real database in sight.
+				Adesso solo se viene invocato il metodo <code>query()</code>
+				di <code>$connection</code> viene restituito l'oggetto <code>$result</code>
+				che si esaurisce la sua funzione dopo la terza chiamata a <code>next()</code>.
+                Dovrebbero esserci abbastanza informazioni perch\xE9 la classe
+				<code>UserFinder</code> possa essere collaudata senza problemi.
+				Un test molto preciso e nessun database reale tra i piedi.
             </p>
             <p>
-                We could refine this test further by insisting that the correct
-                query is sent...
+                E' possibile ulteriormente raffinare questo test richiedendo che venga
+				utilizzata la query corretta:
 <php><![CDATA[
 $connection->returns('selectQuery', $result, array(<strong>'select name, id from people'</strong>));
 ]]></php>
-                This is actually a bad idea.
+                Il realt\xE0 questa \xE8 una cattiva idea.
             </p>
             <p>
-                We have a <code>UserFinder</code> in object land, talking to
-                database tables using a large interface - the whole of SQL.
-                Imagine that we have written a lot of tests that now depend
-                on the exact SQL string passed.
-                These queries could change en masse for all sorts of reasons
-                not related to the specific test.
-                For example the quoting rules could change, a table name could
-                change, a link table added or whatever.
-                This would require the rewriting of every single test any time
-                one of these refactoring is made, yet the intended behaviour has
-                stayed the same.
-                Tests are supposed to help refactoring, not hinder it.
-                I&apos;d certainly like to have a test suite that passes while I change
-                table names.
+				Abbiamo <code>UserFinder</code> che appartiene al mondo degli oggetti
+				e che comunica con le tabelle del database utilizzando un'interfaccia
+				piuttosto estesa, l'intero SQL.
+				Immaginamo di aver scritto molti test come questo che adesso si trovano
+				a dipendere dall'esatta stringa SQL utilizzata.
+				C'\xE8 la possibilit\xE0 che queste query cambino in massa per ragioni non legate
+				allo specifico test. Ad esempio, le regole nell'uso di apici e virgolette
+				potrebbe cambiare, potrebbe essere rinominata una tabella, potrebbe venire
+				aggiunta una link table e cos\xEC via.
+				Queste modifiche richiederebbero la riscrittura di ogni singolo test ogni volta
+				che viene eseguito un refactoring, nonostante il comportamento da collaudare
+				sia fondamentalmente restato inalterato.
+				I test sono pensati per aiutare il refactoring, non per ostacolarlo.
+                Personalmente, preferirei certamente una test suite che non faccia fallire i
+				test solo per un cambio di nome di tabella.
             </p>
             <p>
-                As a rule it is best not to mock a fat interface.
+                Una regola \xE8 quella di non scrivere mock di interfacce troppo complesse.
+				
             </p>
             <p>
-                By contrast, here is the round trip test...
+                Al contrario, ecco come appare un test completo:
 <php><![CDATA[
 class DatabaseTest extends UnitTestCase {<strong>
     function setUp() { ... }
@@ -382,23 +397,24 @@
     }
 }
 ]]></php>
-                This test is immune to schema changes.
-                It will only fail if you actually break the functionality, which
-                is what you want a test to do.
+				Questo collaudo \xE8 immune ai cambiamenti dello schema del db.
+				Fallisce solo se si rompono le funzionalit\xE0 dell'applicazione, cio\xE8
+				quello che intendevamo collaudare.
             </p>
             <p>
-                The catch is those <code>setUp()</code> and <code>tearDown()</code>
-                methods that we&apos;ve rather glossed over.
-                They have to clear out the database tables and ensure that the
-                schema is defined correctly.
-                That can be a chunk of extra work, but you usually have this code
-                lying around anyway for deployment purposes.
+				Il segreto \xE8 nel codice di <code>setUp()</code> e di <code>tearDown()</code>
+				sui quali fino ad ora abbiamo sorvolato.
+				Questi metodi hanno il compito di ripulire le tabelle del database
+				ed assicurare la correttezza dello schema.
+				Realizzare questo risultato pu\xF2 comportare molto lavoro ma generalente 
+				si dispone comunque di codice simile per svolgere il deployment.
             </p>
             <p>
-                One place where you definitely need a mock is simulating failures.
-                Say the database goes down while <code>UserFinder</code> is doing
-                it&apos;s work.
-                Does <code>UserFinder</code> behave well...?
+				Un'area dove si ha veramente bisogno del mocking \xE8 nella simulazione
+				delle anomalie.
+				Supponiamo che il database cada durante il funzionamento di <code>UserFinder</code>
+                
+                <code>UserFinder</code> reagisce come desideriamo?
 <php><![CDATA[
 class DatabaseTest extends UnitTestCase {
 
@@ -412,93 +428,94 @@
     }
 }
 ]]></php>
-                We've passed the <code>UserFinder</code> an <code>$alert</code>
-                object.
-                This is going to do some kind of pretty notifications in the
-                user interface.
-                To pass this test, the finder has to write a nice user friendly
-                message to <code>$alert</code>, rather than propogating the exception.
-                So far, so good.
+				E' stato passato un oggetto <code>$alert</code> a <code>UserFinder</code>.
+				Questo invier\xE0 alcuni messaggi all'interfaccia utente.
+				Per poter passare il test, il finder, piuttostci che propagare 
+				un'eccezione, deve scrivere un messaggio a <code>$alert</code>.
+                				
+				Per adesso, tutto bene.
+                
             </p>
             <p>
-                How do we get the mock <code>DatabaseConnection</code> to throw an exception?
-                We generate the exception using the <code>throwOn</code> method
-                on the mock.
+				Come possiamo dire al mock <code>DatabaseConnection</code> di lanciare l'eccezione?
+                La generiamo usando il metodo <code>throwOn</code>.
             </p>
             <p>
-                Finally, what if the method you want to simulate does not exist yet?
-                If you set a return value on a method that is not there, SimpleTest
-                will throw an error.
-                What if you are using <code>__call()</code> to simulate dynamic methods?
+				Infine, cosa accade se il metodo che intendiamo simulare non esiste affatto?
+				Se si tenta di impostare un valore di ritorno su un metodo che non esiste,
+				SimpleTest lancia un'errore.
+				Perch\xE9 non usare <code>__call()</code> per simulare dinamicamente i metodi?
             </p>
             <p>
-                Objects with dynamic interfaces, using <code>__call</code>, can
-                be problematic with the current mock objects implemntation.
-                You can mock the <code>__call()</code> method, but this is ugly.
-                Why should a test know anything about such low level implementation details?
-                It just wants to simulate the call.
+				L'uso di <code>__call</code> sugli oggetti con interfacce dinamiche
+				nella implementazione corrente dei mock pu\xF2 essere problematico.
+				E' possibile fare il mock del metodo <code>__call()</code> ma \xE8 una soluzione
+				orrenda.
+				Perch\xE9 mail un test dovrebbe prendersi cura di tali dettagli di implementazione?
+				Il test vuole solo simulare la chiamata.
             </p>
             <p>
-                The way round this is to add extra methods to the mock when
-                generating it.
+				La soluzione a questo \xE8 di aggiungere metodi extra al mock durante
+				la sua generazione.
 <php><![CDATA[
 <strong>Mock::generate('DatabaseConnection', 'MockDatabaseConnection', array('setOptions'));</strong>
 ]]></php>
-                In a large test suite this could cause trouble, as you probably
-                already have a mock version of the class called
-                <code>MockDatabaseConnection</code> without the extra methods.
-                The code generator will not generate a mock version of the class if
-                one of the same name already exists.
-                You will confusingly fail to see your method if another definition
-                was run first.
+				In test suite di notevoli dimensioni questo pu\xF2 generare problemi, dal momento
+				che c'\xE8 il rischio di avere gi\xE0 una classe chiamata 
+                <code>MockDatabaseConnection</code> priva dei metodi extra.
+				Il code generator infatti non genera la versione mock di una classe se ne
+				trova un'altra con lo stesso nome.
+				Vedere il proprio metodo fallire perch\xE9 un'altra definizione \xE8 stata
+				invocata precedentemente pu\xF2 essere disorientante.
             </p>
             <p>
-                To cope with this, SimpleTest allows you to choose any name for the
-                new class at the same time as you add the extra methods.
+				Per gestire questa situazione, SimpleTest permette allo sviluppatore
+				di scegliere liberamente il nome della nuova classe nel momento dell'aggiunta
+				dei metodi extra.
 <php><![CDATA[
 Mock::generate('DatabaseConnection', <strong>'MyMockDatabaseConnection'</strong>, array('setOptions'));
 ]]></php>
-                Here the mock will behave as if the <code>setOptions()</code>
-                existed in the original class.
+				In questo esempio il mock si comporta come se <code>setOptions()</code>
+				esistesse nella classe originale.
             </p>
             <p>
-                Mock objects can only be used within test cases, as they send messages,
-                upon expectations, straight to the currently running test case.
-                Creating them outside a test case will cause a run time error
-                when an expectation is triggered.
-                We cover expectations next.
+				Gli oggetti mock possono essere utilizzati solo all'interno dei test case
+				perch\xE9 inviano messaggi, come expectation, direttamente al test case.
+                Lanciarli al di fuori dell'ambiente del test case provocherebbe
+				un run time error non appena la prima expectation fosse invocata.
+				Parleremo delle expectation pi\xF9 avanti.
             </p>
         </section>
         <section name="expectations" title="Mocks as critics">
             <p>
-                Although the server stubs approach insulates your tests from
-                real world disruption, it is only half the benefit.
-                You can have the class under test receiving the required
-                messages, but is your new class sending correct ones?
-                Testing this can get messy without a mock objects library.
+				Nonostante l'approccio dei server stub riesca ad isolare i test
+				dagli sconvolgimenti del mondo, questa \xE8 solo una met\xE0 dei benefici.
+				E' possibile fare in modo che la classe sotto collaudo riceva
+				i messaggi richiesti: ma si riesce a fargli inviare indietro quelli corretti?
+				Il collaudo pu\xF2 diventare un vero inferno senza una libreria di mocking.
             </p>
 			<p>
-                By way of example, let's take a simple <code>PageController</code>
-                class to handle a credit card payment form...
+				Per fare un esempio, consideriamo una semplice classe <code>PageController</code>
+				che gestisca il form per il pagamento con carta di credito:
+                
 <php><![CDATA[
 class PaymentForm extends PageController {
     function __construct($alert, $payment_gateway) { ... }
     function makePayment($request) { ... }
 }
 ]]></php>
-                This class takes a <code>PaymentGateway</code> to actually talk
-                to the bank.
-                It also takes an <code>Alert</code> object to handle errors.
-                This class talks to the page or template.
-                It's responsible for painting the error message and highlighting any
-                form fields that are incorrect.
+				Questa classe utilizza un oggetto <code>PaymentGateway</code> per comunicare
+				fisicamente con la banca ed un oggetto <code>Alert</code> per gestire gli errori.
+				La classe comunica anche alla pagine o al template.
+				E' responsabile della visualizzazione degli errori e dell'evidenziazione
+				di ogni campo del form che non sia stato compilato correttamente.
             </p>
             <p>
-                Our interest is in the <code>makePayment()</code> method.
-                If we fail to enter a &quot;CVV2&quot; number (the three digit number
-                on the back of the credit card), we want to show an error rather than
-                try to process the payment.
-                In test form...
+				Il metodo che ci interessa \xE8 <code>makePayment()</code>.
+				Se viene inserito un numero &quot;CVV2&quot; errato (le ultime 3 cifre
+				sul retro della carta di credito) si vuole che il processo di pagamento non
+				venga nemmeno iniziato e che venga visualizzato invece un errore.
+				Nel test form avremo:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -521,26 +538,27 @@
 }
 ?>
 ]]></php>
-                The first question you may be asking is, where are the assertions?
+				Una domanda sorge spontanea: dove sono gli assert?
             </p>
             <p>
-                The call to <code>expectOnce('warn', array(...))</code> instructs the mock
-                to expect a call to <code>warn()</code> before the test ends.
-                When it gets a call to <code>warn()</code>, it checks the arguments.
-                If the arguments don't match, then a failure is generated.
-                It also fails if the method is never called at all.
+				La chiamata a <code>expectOnce('warn', array(...))</code> indica al mock
+				di attendersi una chiamata a <code>warn()</code> prima che il test termini.
+				Nel momento in cui la chiamata a <code>warn()</code> viene intercettata, il mock verifica
+				gli argomenti utilizzati. Se gli argomenti non corrispondono a quanto
+				stabilito viene generata una failure.
+				Viene generata una failure anche nel caso la chiamata non venga eseguita affatto.
             </p>
             <p>
-                The test above not only asserts that <code>warn</code> was called,
-                but that it received the string &quot;Missing three digit security code&quot;
-                and also the tag &quot;cvv2&quot;.
-                The equivalent of <code>assertIdentical()</code> is applied to both
-                fields when the parameters are compared.
+				Il test appena visti non si milita a verificare che <code>warn</code> venga
+				chiamato ma che vengano ricevuta la stringa &quot;Missing three digit security code&quot;
+				ed il tag &quot;cvv2&quot;.
+				Nel momento della comparazione di entrambi i parametri viene applicato
+				l'equivalente di <code>assertIdentical()</code>.
             </p>
             <p>
-                If you are not interested in the actual message, and we are not
-                for user interface code that changes often, we can skip that
-                parameter with the &quot;*&quot; operator...
+				Nel caso non si sia interessati al messaggio, come accade nel caso
+				di messaggi provenienti dall'interfaccia utente soggetti a molti cambiamenti,
+				\xE8 possibile saltare il parametro con l'operatore &quot;*&quot;:
 <php><![CDATA[
 class PaymentFormFailuresShouldBeGraceful extends UnitTestCase {
 
@@ -554,8 +572,8 @@
     function requestWithMissingCvv2() { ... }
 }
 ]]></php>
-                We can weaken the test further by missing
-                out the parameters array...
+				Possiamo rendere ancora pi\xF9 debole il test tralasciando l'array
+				dei parametri:
 <php><![CDATA[
 function testMissingCvv2CausesAlert() {
     $alert = new MockAlert();
@@ -564,24 +582,26 @@
     $controller->makePayment($this->requestWithMissingCvv2());
 }
 ]]></php>
-                This will only test that the method is called,
-                which is a bit drastic in this case.
-                Later on, we'll see how we can weaken the expectations more precisely.
+				In questo modo l'unico test che verr\xE0 effettuato \xE8 sull'invocazione
+				del metodo, il che pu\xF2 essere un po' eccessivo in questo caso.
+				Pi\xF9 avanti vedremo come indebolire le expectation in modo pi\xF9 selettivo.
             </p>
             <p>
-                Tests without assertions can be both compact and very expressive.
-                Because we intercept the call on the way into an object, here of
-                the <code>Alert</code> class, we avoid having to assert it's state
-                afterwoods.
-                This not only avoids the assertions in the tests, but also having
-                to add extra test only accessors to the original code.
-                If you catch yourself adding such accessors, called &quot;state based testing&quot;,
-                it's probably time to consider using mocks in the tests.
-                This is called &quot;behaviour based testing&quot;, and is normally superior.
+				I test senza assert sono sia compatti che molto espressivi.
+				Siccome la chiamata viene intercettata mentre arriva dall'interno dell'oggetto, in questo
+				caso della classe <code>Alert</code>, non c'\xE8 il bisogno di dichiarare alcun assert sul suo
+				stato.
+				Non solo questo evita gli assert nei test ma anche la necessit\xE0 di aggiungere
+				altri accessor al codice originale.
+                Nel caso ci si dovesse scoprire ad aggiungere accessor al codice, cio\xE8 quelli che
+				comunemente vengono chiamati &quot;state based testing&quot;, potrebbe essere il momento di
+				considerare l'uso dei mock nei propri test.
+				Quest'ultimo approccio \xE8 chiamato &quot;behaviour based testing&quot; ed \xE8 normalmente considerato
+				migliore rispetto all'uso degli accessor.
             </p>
             <p>
-                Let's add another test.
-                Let's make sure that we don't even attempt a payment without a CVV2...
+				Aggiungiamo un altro test.
+				Assicuriamoci che non si riesca nemmeno a tentare un pagamento in assenza del codice CVV2:
 <php><![CDATA[
 class PaymentFormFailuresShouldBeGraceful extends UnitTestCase {
 
@@ -597,17 +617,17 @@
     ...
 }
 ]]></php>
-                Asserting a negative can be very hard in tests, but
-                <code>expectNever()</code> makes it easy.
+				Nei test pu\xF2 risultare molto difficile realizzare l'assert di una condizione negativa
+				ma il metodo <code>expectNever()</code> rende l'operazione semplice:
             </p>
             <p>
-                <code>expectOnce()</code> and <code>expectNever()</code> are
-                sufficient for most tests, but
-                occasionally you want to test multiple events.
-                Normally for usability purposes we want all missing fields
-                in the form to light up, not just the first one.
-                This means that we should get multiple calls to
-                <code>Alert::warn()</code>, not just one...
+                <code>expectOnce()</code> e <code>expectNever()</code> sono pi\xF9 che sufficienti
+				per la maggior parte dei test ma, occasionalmente, si potrebbe aver bisogno di
+				collaudare pi\xF9 eventi.
+				Normalmente, a vantaggio dell'usabilit\xE0, si vuole che vengano evidenziati  tutti i campi
+				non compilati del form e non solo il primo.
+				Allo scopo dovremmo essere in grado di eseguire chiamate multiple
+				a <code>Alert::warn()</code> e non solo una:
 <php><![CDATA[
 function testAllRequiredFieldsHighlightedOnEmptyRequest() {
     $alert = new MockAlert();<strong>
@@ -623,92 +643,93 @@
     $controller->makePayment($this->requestWithMissingCvv2());
 }
 ]]></php>
-                The counter in <code>expectAt()</code> is the number of times
-                the method has been called already.
-                Here we are asserting that every field will be highlighted.
+				Il contatore presente in <code>expectAt()</code> rappresenta il numero
+				di volte per il quale il metodo \xE8 gi\xE0 stato invocato.
+				Qui si sta eseguendo un assert per ogni campo che verr\xE0 evidenziato.
             </p>
             <p>
-                Note that we are forced to assert the order too.
-                SimpleTest does not yet have a way to avoid this, but
-                this will be fixed in future versions.
+				Si noti che siamo costretti a valutare anche l'ordine delle chiamate.
+				SimpleTest non prevede ancora un sistema per evitare questo inconveniente
+				ma lo preveder\xE0 nelle prossime versioni.
             </p>
             <p>
-                Here is the full list of expectations you can set on a mock object
-                in <a href="http://simpletest.org/">SimpleTest</a>.
-                As with the assertions, these methods take an optional failure message.
+				Di seguito \xE8 riportato un elenco delle expectation utilizzabili su un
+				oggetto mock in <a href="http://simpletest.org/">SimpleTest</a>.
+				Cos\xEC come per gli assert, questi metodi accettano un parametro opzionale
+				con il messaggio di failure.
                 <table>
-                    <thead><tr><th>Expectation</th><th>Description</th></tr></thead>
+                    <thead><tr><th>Expectation</th><th>Descrizione</th></tr></thead>
                     <tbody>
                         <tr>
                             <td><code>expect($method, $args)</code></td>
-                            <td>Arguments must match if called</td>
+                            <td>Nel caso il metodo venga invocato, gli argomenti devono corrispondere a quanto dichiarato</td>
                         </tr>
                         <tr>
                             <td><code>expectAt($timing, $method, $args)</code></td>
-                            <td>Arguments must match when called on the <code>$timing</code>'th time</td>
+                            <td>Gli argomenti devono corrispondere alla <code>$timing</code>-esima chiamata</td>
                         </tr>
                         <tr>
                             <td><code>expectCallCount($method, $count)</code></td>
-                            <td>The method must be called exactly this many times</td>
+                            <td>Il metodo deve essere invocato esattamente <code>$count</code> volte</td>
                         </tr>
                         <tr>
                             <td><code>expectMaximumCallCount($method, $count)</code></td>
-                            <td>Call this method no more than <code>$count</code> times</td>
+                            <td>Il metodo deve essere invocato non pi\xF9 di <code>$count</code> volte</td>
                         </tr>
                         <tr>
                             <td><code>expectMinimumCallCount($method, $count)</code></td>
-                            <td>Must be called at least <code>$count</code> times</td>
+                            <td>Il metodo deve essere invocato almeno <code>$count</code> volte</td>
                         </tr>
                         <tr>
                             <td><code>expectNever($method)</code></td>
-                            <td>Must never be called</td>
+                            <td>Il metodo non deve essere mai invocato</td>
                         </tr>
                         <tr>
                             <td><code>expectOnce($method, $args)</code></td>
-                            <td>Must be called once and with the expected arguments if supplied</td>
+                            <td>Il metodo deve essere invocato una sola volta e con i parametri indicati</td>
                         </tr>
                         <tr>
                             <td><code>expectAtLeastOnce($method, $args)</code></td>
-                            <td>Must be called at least once, and always with any expected arguments</td>
+                            <td>Il metodo deve essere invocato almeno una volta e con i parametri indicati</td>
                         </tr>
                     </tbody>
                 </table>
-                Where the parameters are...
+				I parametri sono:
                 <dl>
                     <dt class="new_code">$method</dt>
-                    <dd>The method name, as a string, to apply the condition to.</dd>
+                    <dd>La stringa con il nome del metodo al quale applicare la condizione.</dd>
                     <dt class="new_code">$args</dt>
                     <dd>
-                        The arguments as a list. Wildcards can be included in the same
-                        manner as for <code>setReturn()</code>.
-                        This argument is optional for <code>expectOnce()</code>
-                        and <code>expectAtLeastOnce()</code>.
+						L'elenco degli argomenti. E' possibile utilizzare i caratteri jolly allo
+						stesso modo in cui si utilizzano con <code>setReturn()</code>.
+                        Questo argomento \xE8 opzionale in <code>expectOnce()</code>
+                        e in <code>expectAtLeastOnce()</code>.
                     </dd>
                     <dt class="new_code">$timing</dt>
                     <dd>
-                        The only point in time to test the condition.
-                        The first call starts at zero and the count is for
-                        each method independently.
+						L'istante in cui valutare la consizione.
+						La prima chiamata inizia con 0 ed i conteggi delle chiamate ai vari
+						metodi sono indipendenti tra loro.
                     </dd>
                     <dt class="new_code">$count</dt>
-                    <dd>The number of calls expected.</dd>
+                    <dd>Il numero di invocazioni attese</dd>
                 </dl>
             </p>
             <p>
-                If you have just one call in your test, make sure you're using
-                <code>expectOnce</code>.<br />
-                Using <code>$mocked->expectAt(0, 'method', 'args);</code>
-                on its own will allow the method to never be called.
-                Checking the arguments and the overall call count
-                are currently independant.
-                Add an <code>expectCallCount()</code> expectation when you
-                are using <code>expectAt()</code> unless zero calls is allowed.
+				Nel caso si abbia una sola chiamata nel test, \xE8 bene assicurarsi
+				di usare <code>expectOnce</code>.<br />
+                L'uso di <code>$mocked->expectAt(0, 'method', 'args);</code>
+				consertirebbe al metodo di non essere mai invocato.
+				Il controllo degli argomenti ed il controllo del numero totale di chiamate 
+				sono operazioni indipendenti.
+				Quando si usa <code>expectAt()</code>, deve essere aggiunta la chiamata a <code>expectCallCount()</code> 
+				altrimenti risulter\xE0 consentito non invocare mai il metodo.
             </p>
             <p>
-                Like the assertions within test cases, all of the expectations
-                can take a message override as an extra parameter.
-                Also the original failure message can be embedded in the output
-                as &quot;%s&quot;.
+				Come per gli assert nei test case, tutte le expectation accettano come terzo parametro un
+				messaggio con il quale sovrascrivere il messaggio di default.
+				Come nell'altro caso, inoltre, il messaggio di default pu\xF2 essere
+				recuperato mediante &quot;%s&quot;.
             </p>
         </section>
     </content>

Modified: simpletest/trunk/docs/source/it/unit_test_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/unit_test_documentation.xml	2009-09-06 18:07:34 UTC (rev 1948)
+++ simpletest/trunk/docs/source/it/unit_test_documentation.xml	2009-09-08 13:20:51 UTC (rev 1949)
@@ -17,7 +17,7 @@
 				inizino per default con la stringa &quot;test&quot; in modo che quando
 				il test case viene invocato essi vengano lanciato nello stesso ordine
 				in cui l'introspezione di PHP li trova.
-				Possono essere aggiunti quanti metodi di test si desideri.
+				Possono essere aggiunti quanti metodi di test si vuole.
             </p>
             <p>
                 Per esempio:


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 1951
          http://simpletest.svn.sourceforge.net/simpletest/?rev=1951&view=rev
Author:   arialdomartini
Date:     2009-09-14 16:14:29 +0000 (Mon, 14 Sep 2009)

Log Message:
-----------
Italian pages converted to UTF8.
New pages translated.

Modified Paths:
--------------
    simpletest/trunk/docs/source/en/reporter_documentation.xml
    simpletest/trunk/docs/source/it/about.xml
    simpletest/trunk/docs/source/it/authentication_documentation.xml
    simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml
    simpletest/trunk/docs/source/it/browser_documentation.xml
    simpletest/trunk/docs/source/it/display_subclass_tutorial.xml
    simpletest/trunk/docs/source/it/expectation_documentation.xml
    simpletest/trunk/docs/source/it/first_test_tutorial.xml
    simpletest/trunk/docs/source/it/form_testing_documentation.xml
    simpletest/trunk/docs/source/it/gain_control_tutorial.xml
    simpletest/trunk/docs/source/it/group_test_documentation.xml
    simpletest/trunk/docs/source/it/group_test_tutorial.xml
    simpletest/trunk/docs/source/it/improving_design_tutorial.xml
    simpletest/trunk/docs/source/it/mock_objects_documentation.xml
    simpletest/trunk/docs/source/it/mock_objects_tutorial.xml
    simpletest/trunk/docs/source/it/overview.xml
    simpletest/trunk/docs/source/it/partial_mocks_documentation.xml
    simpletest/trunk/docs/source/it/reporter_documentation.xml
    simpletest/trunk/docs/source/it/simple_test.xml
    simpletest/trunk/docs/source/it/subclass_tutorial.xml
    simpletest/trunk/docs/source/it/unit_test_documentation.xml
    simpletest/trunk/docs/source/it/web_tester_documentation.xml

Modified: simpletest/trunk/docs/source/en/reporter_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/en/reporter_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/en/reporter_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -98,7 +98,7 @@
                         The first start event is usually delivered by the top level group
                         test and so this is where <code>$test_name</code>
                         comes from.
-                        It paints the page titles, CSS, body tag, etc.
+                        It paints the page title, CSS, body tag, etc.
                         It returns nothing (<code>void</code>).
                     </li>
                     <li>
@@ -438,7 +438,7 @@
             Using <a href="#cli">SimpleTest from the command line</a>
         </link>
         <link>
-            Using <a href="#xml">Using XML</a> for remote testing
+            <a href="#xml">Using XML</a> for remote testing
         </link>
     </internal>
     <external>

Modified: simpletest/trunk/docs/source/it/about.xml
===================================================================
--- simpletest/trunk/docs/source/it/about.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/about.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,7 @@
 <?xml version="1.0"?>
 <!-- $Id: about.xml 1803 2008-09-08 11:11:03Z lastcraft $ -->
-<page title="About Last Craft" here="About">
+<page title="Informazioni su Last Craft" here="Informazioni su Last Craft">
+	<synchronisation lang="en" version="1684" date="19/03/2008" maintainer="pp11" />
     <long_title>Informazioni su Last Craft</long_title>
     <content>
         <section name="me" title="People">
@@ -13,20 +14,20 @@
                 Attualmente sono un freelancer che lavora come sviluppatore senior per
                 <a href="http://www.wordtracker.com">Wordtracker</a>
                 e come consulente per svariate piccole compagnie.
-                Wordtracker \xE8 un'agenzia di statistica su internet che gestisce un immenso
-                 database sulla popolarit\xE0 delle parole chiave dei motori di ricerca.
+                Wordtracker è un'agenzia di statistica su internet che gestisce un immenso
+                 database sulla popolarità delle parole chiave dei motori di ricerca.
                 La compagnia adotta la metodologia di sviluppo eXtreme Programming.
             </p>
             <p>
-                Mia moglie <a href="mailto:aviva@... Racher</a> \xE8 una
-                microbiologa ed \xE8 la madre dei miei due bambini.
+                Mia moglie <a href="mailto:aviva@... Racher</a> è una
+                microbiologa ed è la madre dei miei due bambini.
             </p>
         </section>
         <section name="issues" title="Issues">
             <p>
                 Leggi l'intervista <a
                 href="http://www.oreillynet.com/pub/a/patents/2000/05/24/PizzoFiles.html">
-                Chi pu\xF2 sentirsi davvero protetto?</a> sul network di
+                Chi può sentirsi davvero protetto?</a> sul network di
                 O&#39;Reilly se sei interessato all'argomento delle licenze software.
             </p>
         </section>

Modified: simpletest/trunk/docs/source/it/authentication_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/authentication_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/authentication_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: authentication_documentation.xml 1803 2008-09-08 11:11:03Z lastcraft $ -->
-<page title="Authentication documentation" here="Authentication">
+<page title="L'autenticazione" here="L'autenticazione">
     <long_title>SimpleTest documentation for testing log-in and authentication</long_title>
     <content>
         <introduction>
@@ -11,7 +11,7 @@
                 the SimpleTest web tester.
             </p>
         </introduction>
-        <section name="basic" title="Basic HTTP authentication">
+        <section name="basic" title="Autenticazione HTTP di base">
             <p>
                 If you fetch a page protected by basic authentication then
                 rather than receiving content, you will instead get a 401
@@ -127,7 +127,7 @@
                 in the future if enough people request this feature.
             </p>
         </section>
-        <section name="cookies" title="Cookies">
+        <section name="cookies" title="I Cookie">
             <p>
                 Basic authentication doesn't give enough control over the
                 user interface for web developers.
@@ -230,7 +230,7 @@
                 Is your site protected from this attack?
             </p>
         </section>
-        <section name="session" title="Browser sessions">
+        <section name="session" title="Le sessioni del browser">
             <p>
                 If you are testing an authentication system a critical piece
                 of behaviour is what happens when a user logs back in.

Modified: simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/boundary_classes_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: boundary_classes_tutorial.xml 1879 2009-06-12 16:41:44Z pp11 $ -->
-<page title="The Application Boundary" here="Boundary classes">
+<page title="Le classi boundary" here="Tutorial: le classi boundary">
     <long_title>
         PHP unit testing tutorial - Organising unit tests and &quot;setup tests&quot;
     </long_title>

Modified: simpletest/trunk/docs/source/it/browser_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/browser_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/browser_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: browser_documentation.xml 1803 2008-09-08 11:11:03Z lastcraft $ -->
-<page title="PHP Scriptable Web Browser" here="Scriptable browser">
+<page title="Scripting del browser" here="Scripting del browser">
     <long_title>SimpleTest documentation for the scriptable web browser component</long_title>
     <content>
         <introduction>
@@ -10,7 +10,7 @@
                 independently of the SimpleTest framework itself.
             </p>
         </introduction>
-        <section name="scripting" title="The Scriptable Browser">
+        <section name="scripting" title="Lo scripting del browser">
             <p>
                 You can use the web browser in PHP scripts to confirm
                 services are up and running, or to extract information
@@ -129,7 +129,7 @@
                 This includes links to click and forms to submit.
             </p>
         </section>
-        <section name="debug" title="What went wrong?">
+        <section name="debug" title="Cosa è andato storto?">
             <p>
                 All of this functionality is great when we actually manage to fetch pages,
                 but that doesn't always happen.
@@ -168,7 +168,7 @@
                 see what happened.
             </p>
         </section>
-        <section name="unit" title="Complex unit tests with multiple browsers">
+        <section name="unit" title="Unit test complessi con più browser">
             <p>
                 Anything that could be done in a
                 <a local="web_tester_documentation">WebTestCase</a> can

Modified: simpletest/trunk/docs/source/it/display_subclass_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/display_subclass_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/display_subclass_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: display_subclass_tutorial.xml 1876 2009-06-12 16:30:24Z pp11 $ -->
-<page title="Changing the test display" here="Showing passes">
+<page title="Visualizzare i risultati" here="Tutorial: visualizzare i risultati">
     <long_title>PHP unit testing tutorial - Subclassing the test display</long_title>
     <content>
         <introduction>

Modified: simpletest/trunk/docs/source/it/expectation_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/expectation_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/expectation_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,11 +1,11 @@
 <?xml version="1.0"?>
 <!-- $Id: expectation_documentation.xml 1873 2009-06-12 16:12:18Z pp11 $ -->
-<page title="Expectation documentation" here="Expectations">
+<page title="Le expectation" here="Le expectation">
     <long_title>
         Extending the SimpleTest unit tester with additional expectation classes
     </long_title>
     <content>
-        <section name="mock" title="More control over mock objects">
+        <section name="mock" title="Maggiore controllo sugli oggetti mock">
             <p>
                 The default behaviour of the
                 <a local="mock_objects_documentation">mock objects</a>
@@ -161,7 +161,7 @@
                 This will accept any value from 13.999 to 14.001 inclusive.
             </p>
         </section>
-        <section name="behaviour" title="Using expectations to control stubs">
+        <section name="behaviour" title="Usare le expectation per controllare gli stub">
             <p>
                 The expectation classes can be used not just for sending assertions
                 from mock objects, but also for selecting behaviour for the
@@ -197,7 +197,7 @@
                 completeness.
             </p>
         </section>
-        <section name="extending" title="Creating your own expectations">
+        <section name="extending" title="Crearsi le proprie expectation">
             <p>
                 The expectation classes have a very simple structure.
                 So simple that it is easy to create your own versions for
@@ -275,7 +275,7 @@
 ]]></php>
             </p>
         </section>
-        <section name="unit" title="Under the bonnet of the unit tester">
+        <section name="unit" title="Dentro il cofano dello unit tester">
             <p>
                 The <a href="http://sourceforge.net/projects/simpletest/">SimpleTest unit testing framework</a>
                 also uses the expectation classes internally for the

Modified: simpletest/trunk/docs/source/it/first_test_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/first_test_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/first_test_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: first_test_tutorial.xml 1941 2009-08-10 10:09:32Z pp11 $ -->
-<page title="Creating a new test case" here="PHP unit testing">
+<page title="Tutorial rapido" here="Tutorial rapido">
     <long_title>PHP unit testing tutorial - Creating an example test case in PHP</long_title>
     <content>
         <introduction>

Modified: simpletest/trunk/docs/source/it/form_testing_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/form_testing_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/form_testing_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,9 +1,9 @@
 <?xml version="1.0"?>
 <!-- $Id: form_testing_documentation.xml 1812 2008-09-27 01:46:42Z lastcraft $ -->
-<page title="Form testing documentation" here="Testing forms">
+<page title="Il collaudo di form" here="Il collaudo di form">
     <long_title>SimpleTest documentation for testing HTML forms</long_title>
     <content>
-        <section name="submit" title="Submitting a simple form">
+        <section name="submit" title="Fare il Submit di un semplice form">
             <p>
                 When a page is fetched by the <code>WebTestCase</code>
                 using <code>get()</code> or
@@ -142,7 +142,7 @@
                 commands. See below for a way to test such forms.
             </p>
         </section>
-        <section name="multiple" title="Fields with multiple values">
+        <section name="multiple" title="Campi con valori multipli">
             <p>
                 SimpleTest can cope with two types of multivalue controls: Multiple
                 selection drop downs, and multiple checkboxes with the same name
@@ -199,7 +199,7 @@
                 by logging in as that user and attempting an update.
             </p>
         </section>
-        <section name="hidden-field" title="Forms which use javascript to set a hidden field">
+        <section name="hidden-field" title="Form che utilizzano Javascript per popolare campi nascosti">
             <p>
                 If you want to test a form which relies on javascript to set a hidden
                 field, you can't just call setField().

Modified: simpletest/trunk/docs/source/it/gain_control_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/gain_control_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/gain_control_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: gain_control_tutorial.xml 1867 2009-03-05 15:49:54Z lastcraft $ -->
-<page title="Taking control of testing" here="Taking control">
+<page title="Prendere il controllo dei test" here="Tutorial: prendere il controllo">
     <long_title>PHP unit testing tutorial - Isolating variables when testing</long_title>
     <content>
         <introduction>

Modified: simpletest/trunk/docs/source/it/group_test_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/group_test_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/group_test_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,12 +1,12 @@
 <?xml version="1.0"?>
 <!-- $Id: group_test_documentation.xml 1878 2009-06-12 16:39:37Z pp11 $ -->
-<page title="Test suite documentation" here="Group tests">
+<page title="Raggruppamento di test" here="Raggruppamento di test">
     <long_title>SimpleTest for PHP test suites</long_title>
     <content>
-        <section name="group" title="Grouping tests into suites">
+        <section name="group" title="Raggruppare i test in suite">
             <p>
 				Eistono molti sistemi per raggruppare i test in test suite.
-				Uno di questi \xE8 quello di mettere semplicemente pi\xF9 test case in un singolo file:
+				Uno di questi è quello di mettere semplicemente più test case in un singolo file:
 <php><![CDATA[
 <strong><?php
 require_once(dirname(__FILE__) . '/simpletest/autorun.php');
@@ -23,7 +23,7 @@
 ]]></php>
 				E' possibile mettere quanti test case si vuole in ogni file.
 				Ogni file necessario all'esecuzione, come ad esempio la libreria da
-				collaudare, dovrebbe essere incluso ma non \xE8 necessario includere
+				collaudare, dovrebbe essere incluso ma non è necessario includere
 				alcuna libreria di SimpleTest.
             </p>
             <p>
@@ -44,7 +44,7 @@
             </p>
             <p>
 				Chiameremo questo file di esempio <em>file_test.php</em>.
-				Il passo successivo \xE8 quello di creare il file della test suite
+				Il passo successivo è quello di creare il file della test suite
 				che potremmo chiamare <em>my_test_suite.php</em>.
                 Sono certo che saprai trovare nomi migliori di questo.
             </p>
@@ -63,17 +63,17 @@
 }
 ?>
 ]]></php>
-				Quello che accadr\xE0 \xE8 che la classe <code>TestSuite</code>
-				penser\xE0 autonomamente ad eseguire i <code>require_once()</code>
-				necessari, controller\xE0 se nuove classi di test case sono presenti nel
-				file e all'occorrenza li aggiunger\xE0 alla test suite.
+				Quello che accadrà è che la classe <code>TestSuite</code>
+				penserà autonomamente ad eseguire i <code>require_once()</code>
+				necessari, controllerà se nuove classi di test case sono presenti nel
+				file e all'occorrenza li aggiungerà alla test suite.
 				
                 Questo metodo ci fornisce il massimo del controllo.
             </p>
             <p>
 				Nel caso questo metodo sembrasse troppo prolisso e si desiderasse
-				di raggruppare tra loro pi\xF9 test suite di una stessa directory oppure in
-				base al loro nome del file, esiste un metodo ancora pi\xF9 automatico:
+				di raggruppare tra loro più test suite di una stessa directory oppure in
+				base al loro nome del file, esiste un metodo ancora più automatico:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -90,32 +90,32 @@
 				Questo sistema ricerca nella directory &quot;unit&quot; i file
 				il cui nome termina per &quot;_test.php&quot; e li carica.
 				L'uso di <code>SimplePatternCollector</code> per filtrare in
-				base ad un pattern non \xE8 obbligatorio ma \xE8 il sistema pi\xF9 comune.
+				base ad un pattern non è obbligatorio ma è il sistema più comune.
             </p>
             <p>
-				Tutto quel che resta da fare adesso \xE8 creare un file nella directory 
-				dei test case che lancer\xE0 lo script della test suite.
+				Tutto quel che resta da fare adesso è creare un file nella directory 
+				dei test case che lancerà lo script della test suite.
             </p>
             <p>
 				I test case caricati con il metodo <code>addFile</code> posseggono
-				alcune utili propriet\xE0.
+				alcune utili proprietà.
 				Si ha la certezza che il costruttore sia invocato prima del lancio del
 				primo test e il distruttore dopo l'esecuzione dell'ultimo.
 				Questo consente di ospitare nel costruttore e nel distruttore
 				il codice di set up e di tear down che deve valere per tutto il test case.
             </p>
         </section>
-        <section name="higher" title="Composite suites">
+        <section name="higher" title="Suite composite">
             <p>
 				Il metodo appena presentato prevede di ospitare tutti i test case in
 				un'unica grande test suite.
 				Per progetti di grandi dimensione, tuttavia, questo metodo non risulta
-				abbastanza flessibile perch\xE9 si potrebbe desiderare di raggrupare 
-				test nelle pi\xF9 varie modalit\xE0.
+				abbastanza flessibile perché si potrebbe desiderare di raggrupare 
+				test nelle più varie modalità.
             </p>
             <p>
-				Per poter disporre di un group test pi\xF9 flessibile
-				\xE8 possibile istanziare una classe che erediti da <code>TestSuite</code>:
+				Per poter disporre di un group test più flessibile
+				è possibile istanziare una classe che erediti da <code>TestSuite</code>:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -128,8 +128,8 @@
 }</strong>
 ?>
 ]]></php>
-				In questo modo si \xE8 aggiunta una test suite dentro un'altra.
-				In questo caso non risulta molto utile ma \xE8 possibile aggiungere
+				In questo modo si è aggiunta una test suite dentro un'altra.
+				In questo caso non risulta molto utile ma è possibile aggiungere
 				altre suite a piacimento.
 				E' perfino possibile mescolare gruppi e singoli test case a patto
 				di prestare attenzione alle inclusioni multiple.
@@ -146,7 +146,7 @@
 }
 ?>
 ]]></php>
-                Nel caso si includa un file pi\xF9 di una volta, verrebbe eseguita
+                Nel caso si includa un file più di una volta, verrebbe eseguita
 				solo la prima istanza del test.
             </p>
         </section>

Modified: simpletest/trunk/docs/source/it/group_test_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/group_test_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/group_test_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: group_test_tutorial.xml 1867 2009-03-05 15:49:54Z lastcraft $ -->
-<page title="Grouping tests" here="Grouping tests">
+<page title="Raggruppamento di test" here="Tutorial: Raggruppamento di test">
     <long_title>
         PHP unit testing tutorial - Grouping together unit
         tests and examples of writing test cases

Modified: simpletest/trunk/docs/source/it/improving_design_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/improving_design_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/improving_design_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: improving_design_tutorial.xml 1873 2009-06-12 16:12:18Z pp11 $ -->
-<page title="Top down and test driven" here="Top down testing">
+<page title="Test con l'approccio top-down" here="Tutorial: test con l'approccio top-down">
     <long_title>
         PHP unit testing tutorial - Top down design
         test first with mock objects

Modified: simpletest/trunk/docs/source/it/mock_objects_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/mock_objects_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/mock_objects_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,9 +1,9 @@
 <?xml version="1.0"?>
 <!-- $Id: mock_objects_documentation.xml 1890 2009-07-26 12:09:04Z lastcraft $ -->
-<page title="Mock objects documentation" here="Mock objects">
+<page title="Gli oggetti mock" here="Gli oggetti mock">
     <long_title>SimpleTest for PHP mock objects documentation</long_title>
     <content>
-        <section name="what" title="What are mock objects?">
+        <section name="what" title="Cosa sono gli oggetti mock?">
             <p>
 				Gli oggetti mock svolgono due ruoli durante un test case: il ruolo di "attori"
 				ed il ruolo di "critici"
@@ -12,18 +12,18 @@
                 Nel ruolo di attore il mock ha la funzione di simulare il
 				comportamento di un altro oggetto che durante il test sarebbe
 				difficile o oneroso da instanziare.
-				L'esempio classico \xE8 quello di una connessione ad un database.
+				L'esempio classico è quello di una connessione ad un database.
 				Allestire un database di collaudo all'inizio di ogni singolo testo
 				rallenterebbe il collaudo a livelli inaccettabile e richiederebbe
 				l'istallazione di un apposito motore di database e di dati di test sul
 				server di test.
-                Se ci fosse la possibilit\xE0 di similare la connessione e restituire
+                Se ci fosse la possibilità di similare la connessione e restituire
 				i dati selezionati per il collaudo non solo si otterrebbero dei
-				test pi\xF9 pragmatici ma ci si potrebbe permettere di alimentare il
+				test più pragmatici ma ci si potrebbe permettere di alimentare il
 				codice con dati spuri per vederne la reazione.
-				Avremmo la possibilit\xE0 di simulare il caso di un database fuori linea o
-				altre condizioni estreme di questo tipo, senza la necessit\xE0 di generare
-				i malfunzionamenti nella realt\xE0.
+				Avremmo la possibilità di simulare il caso di un database fuori linea o
+				altre condizioni estreme di questo tipo, senza la necessità di generare
+				i malfunzionamenti nella realtà.
 				In altre parole, i mock possono fornire un grande controllo dell'ambiente
 				di test.
             </p>
@@ -35,11 +35,11 @@
                 Addison-Wesley) nel 1999.
             </p>
             <p>
-				Un server stub \xE8 la simulazione di un oggetto o di un componente.
+				Un server stub è la simulazione di un oggetto o di un componente.
 				Dovrebbe rimpiazzare esplicitamente un componente con lo scopo di
 				permettere il test o la prototipazione ma, fondamentalmente, resta un
 				componente leggero.
-				In questo modo permette ai test di eseguirsi con rapidit\xE0; nel caso
+				In questo modo permette ai test di eseguirsi con rapidità; nel caso
 				la classe simulata ancora non esista affatto, permettono di eseguire
 				comunque il codice.
             </p>
@@ -59,12 +59,12 @@
 				in grado di verificare l'oggetto chiamante stia usando una query, supponiamo
 				SQL, formalmente corretta.
 				Una volta preparai con expectation sufficientemente rigorose
-				non si avr\xE0 pi\xF9 bisogno di eseguire manualmente gli assert.
+				non si avrà più bisogno di eseguire manualmente gli assert.
             </p>
         </section>
-        <section name="creation" title="Creating mock objects">
+        <section name="creation" title="Creare oggetti mock">
             <p>
-				Tutto quello di cui abbiamo bisogno \xE8 una classe esistente,
+				Tutto quello di cui abbiamo bisogno è una classe esistente,
 				supponiamo per la connessione al database, che abbia
 				questo aspetto:
 <php><![CDATA[
@@ -74,8 +74,8 @@
     function selectQuery($sql) { }
 }</strong>
 ]]></php>
-				Non c'\xE8 bisogno che la classe sia stata implementata.
-				Pu\xF2 bastare la sua interfaccia:
+				Non c'è bisogno che la classe sia stata implementata.
+				Può bastare la sua interfaccia:
 <php><![CDATA[
 <strong>interface DatabaseConnection {
     function DatabaseConnection();
@@ -93,7 +93,7 @@
 ]]></php>
 				Questo genera una classe clone
 				chiamata <code>MockDatabaseConnection</code>.
-				Adesso \xE8 possibile istanziare la nuova classe
+				Adesso è possibile istanziare la nuova classe
 				all'interno del test case:
 <php><![CDATA[
 require_once('simpletest/autorun.php');
@@ -145,30 +145,30 @@
             </p>
             <p>
                 Modificare il valore di ritorno di un metodo da <code>null</code>
-				a qualcos'altro \xE8 abbastanza semplice:
+				a qualcos'altro è abbastanza semplice:
 <php><![CDATA[
 <strong>$connection->returns('query', 37)</strong>
 ]]></php>
                 Adesso, ogni invocazione di
                 <code><![CDATA[$connection->query()]]></code> restituisce 37.
-                38 non ha niente di speciale: il valore di ritorno pu\xF2
+                38 non ha niente di speciale: il valore di ritorno può
 				essere arbitrariamente complesso.
             </p>
             <p>
 				I parametri, in questo caso, sono irrilevanti e 
 				una volta che si sia impostato il mock con questo
-				sistema si otterr\xE0 sempre il medesimo valore qualsiasi essi siano
+				sistema si otterrà sempre il medesimo valore qualsiasi essi siano
                 Questa potrebbe apparire una replica poco convincente di una
 				connessione al database, ma per un metodo di test di
-				una mezza dozzina di righe, solitamente, \xE8 tutto quello
-				di cui si pu\xF2 aver bisogno.
+				una mezza dozzina di righe, solitamente, è tutto quello
+				di cui si può aver bisogno.
             </p>
             <p>
-				Tuttavia, le cose non sono sempre cos\xEC semplici.
+				Tuttavia, le cose non sono sempre così semplici.
 				Uno dei problemi comuni si propone con le iterazioni, nelle quali
-				il ritorno sistematico del solito valore pu\xF2 causare cicli
+				il ritorno sistematico del solito valore può causare cicli
 				infiniti dentro l'oggetto da collaudare.
-				Per questo c'\xE8 bisogno di poter impostare sequenze di valori.
+				Per questo c'è bisogno di poter impostare sequenze di valori.
 				Supponiamo di avere una semplice iterazione come questa:
 <php><![CDATA[
 class Iterator {
@@ -176,10 +176,10 @@
     function next() { }
 }
 ]]></php>
-				Stiamo parlando dell'iterazione pi\xF9 semplice che possa capitare.
+				Stiamo parlando dell'iterazione più semplice che possa capitare.
 				Se si assume che questa iterazione restituisca del testo
 				fino a quando raggiunge la fine e che da quel momento
-				debba restituire false, si potrebbe simularla cos\xEC:
+				debba restituire false, si potrebbe simularla così:
 <php><![CDATA[
 Mock::generate('Iterator');
 
@@ -195,17 +195,17 @@
 }
 ]]></php>
 				Quando <code>next()</code> di <code>MockIterator</code> viene invocata
-				restituir\xE0 &quot;First string&quot; la prima volta e &quot;Second string&quot; la
+				restituirà &quot;First string&quot; la prima volta e &quot;Second string&quot; la
 				seconda mentre false tutte le altre volte.
 				I valori di ritorno delle sequenze hanno precedenza sul valori
 				di ritorno costante.
-				Se pu\xF2 essere utile, si pu\xF2 pensare al valore di ritorno costante
+				Se può essere utile, si può pensare al valore di ritorno costante
 				come il valore di ritorno di default.
             </p>
             <p>
-				Un'altra situazione delicata \xE8 il caso di un'operazione 
+				Un'altra situazione delicata è il caso di un'operazione 
                 <code>get()</code> overloaded.
-				Ad esempio \xE8 quando un'informazione conservata con una coppia nome/valore.
+				Ad esempio è quando un'informazione conservata con una coppia nome/valore.
 				Supponiamo di avere una classe di configurazione come questa:
 <php><![CDATA[
 class Configuration {
@@ -213,10 +213,10 @@
     function get($key) { ... }
 }
 ]]></php>
-				Questo \xE8 la tipica situazione in cui un oggetto mock risulta
-				utile, dal momento che la configurazione variet\xE0 da macchina
+				Questo è la tipica situazione in cui un oggetto mock risulta
+				utile, dal momento che la configurazione varietà da macchina
 				a macchina e perfino da test a test.
-				Tuttavia, il problema \xE8 che i dati vengono recuperati mediante
+				Tuttavia, il problema è che i dati vengono recuperati mediante
 				la chiamata al metodo <code>get()</code> e che, contemporaneamente,
 				si desiderano valori differenti in corrispondenza di chiavi differenti.
 				Fortunatamente, i mock dispongono di un sistema di filtraggio:
@@ -226,7 +226,7 @@
 $config->returns('get', 'admin', array('db_user'));
 $config->returns('get', 'secret', array('db_password'));</strong>
 ]]></php>
-				Il parametro aggiunto \xE8 l'elenco degli argomenti con
+				Il parametro aggiunto è l'elenco degli argomenti con
 				i quali provare a fare un match.
 				In questo caso, ad esempio, si sta provando il match con il solo
 				argomento a disposizione il quale viene usato come look up key.
@@ -235,8 +235,8 @@
 <php><![CDATA[
 $config->get('db_user')
 ]]></php>
-                ...restituir\xE0 &quot;admin&quot;.
-				Il risultato \xE8 stato ricavato tentando il match degli argomenti
+                ...restituirà &quot;admin&quot;.
+				Il risultato è stato ricavato tentando il match degli argomenti
 				richiesti con ognuno dei valori dell'elenco, fino a che un match
 				completo viene individuato.
             </p>
@@ -245,18 +245,18 @@
 <php><![CDATA[<strong>
 $config->returns('get', false, array('*'));</strong>
 ]]></php>
-				Questo non \xE8 equivalente ad impostare il valore di
+				Questo non è equivalente ad impostare il valore di
 				ritorno che si deve avere in assenza di argomenti, come accade con:
 <php><![CDATA[<strong>
 $config->returns('get', false);</strong>
 ]]></php>
 				Nel primo caso, viene accettato qualsiasi singolo argomento ma
-				un argomento \xE8 comunque richiesto.
+				un argomento è comunque richiesto.
                 Il secondo caso accetta un qualsiasi numero di argomenti e
-				viene considerato nel caso siano gi\xE0 stati tentati tutti gli altri match.
+				viene considerato nel caso siano già stati tentati tutti gli altri match.
 				
 				Si noti che se nel primo caso si aggiungesse ulteriori parametri
-				dopo il carattere jolly questi verrebbero ignorati perch\xE9 
+				dopo il carattere jolly questi verrebbero ignorati perché 
 				la condizione sul carattere jolly verrebbe soddisfatta prima della
 				loro valutazione.
 				
@@ -264,7 +264,7 @@
 				potrebbe essere importante e si corre il rischio di avere delle
 				corrispondenze che vengono mascherate da caretteri jolly dichiarati
 				prima.
-				Nel caso di dubbi \xE8 meglio dichiarare i match pi\xF9 specifici all'inzio.
+				Nel caso di dubbi è meglio dichiarare i match più specifici all'inzio.
 
             </p>
             <p>
@@ -290,7 +290,7 @@
     ...
 }
 ]]></php>
-				Con questa soluzione si \xE8 certi che ogni volta che viene
+				Con questa soluzione si è certi che ogni volta che viene
 				invocato  <code><![CDATA[$pad->note(3)]]></code> viene
 				restituito sempre il medesimo oggetto <code>$note</code>, perfino
 				quando questo viene modificato.
@@ -308,18 +308,18 @@
 ]]></php>
 				Questo restituisce un riferimento a <code>$buy_books</code> e
 				successivamente a <code>$write_code</code>, ma solo sei i due
-				paramtri risultano impostati ed il secondo \xE8 l'intero 3.
+				paramtri risultano impostati ed il secondo è l'intero 3.
 				In questo modo ogni esigenza dovrebbe risultare soddisfatta.
             </p>
             <p>
-				Un ultimo caso delicato \xE8 quello di un oggetto che ne instanzia un
-				altro, ovvero quello che \xE8 conosciuto come factory pattern.
+				Un ultimo caso delicato è quello di un oggetto che ne instanzia un
+				altro, ovvero quello che è conosciuto come factory pattern.
                 Supponiamo che una query al nostro immaginario database abbia successo
 				e che venga restituito un result set nella forma di iteratore in modo
 				che ad ogni chiamata del metodo <code>next()</code> dell'iteratore venga fornita una
 				riga o il valore false.
-				L'idea di dover simulare un comportamento simile pu\xF2 sembrare da incubo ma
-				in realt\xE0 pu\xF2 essere realizzata con un mock con il meccanismi gi\xE0 presentati:
+				L'idea di dover simulare un comportamento simile può sembrare da incubo ma
+				in realtà può essere realizzata con un mock con il meccanismi già presentati:
 <php><![CDATA[
 Mock::generate('DatabaseConnection');
 Mock::generate('ResultIterator');
@@ -346,7 +346,7 @@
 				Adesso solo se viene invocato il metodo <code>query()</code>
 				di <code>$connection</code> viene restituito l'oggetto <code>$result</code>
 				che si esaurisce la sua funzione dopo la terza chiamata a <code>next()</code>.
-                Dovrebbero esserci abbastanza informazioni perch\xE9 la classe
+                Dovrebbero esserci abbastanza informazioni perché la classe
 				<code>UserFinder</code> possa essere collaudata senza problemi.
 				Un test molto preciso e nessun database reale tra i piedi.
             </p>
@@ -356,7 +356,7 @@
 <php><![CDATA[
 $connection->returns('selectQuery', $result, array(<strong>'select name, id from people'</strong>));
 ]]></php>
-                Il realt\xE0 questa \xE8 una cattiva idea.
+                Il realtà questa è una cattiva idea.
             </p>
             <p>
 				Abbiamo <code>UserFinder</code> che appartiene al mondo degli oggetti
@@ -364,10 +364,10 @@
 				piuttosto estesa, l'intero SQL.
 				Immaginamo di aver scritto molti test come questo che adesso si trovano
 				a dipendere dall'esatta stringa SQL utilizzata.
-				C'\xE8 la possibilit\xE0 che queste query cambino in massa per ragioni non legate
+				C'è la possibilità che queste query cambino in massa per ragioni non legate
 				allo specifico test. Ad esempio, le regole nell'uso di apici e virgolette
 				potrebbe cambiare, potrebbe essere rinominata una tabella, potrebbe venire
-				aggiunta una link table e cos\xEC via.
+				aggiunta una link table e così via.
 				Queste modifiche richiederebbero la riscrittura di ogni singolo test ogni volta
 				che viene eseguito un refactoring, nonostante il comportamento da collaudare
 				sia fondamentalmente restato inalterato.
@@ -376,7 +376,7 @@
 				test solo per un cambio di nome di tabella.
             </p>
             <p>
-                Una regola \xE8 quella di non scrivere mock di interfacce troppo complesse.
+                Una regola è quella di non scrivere mock di interfacce troppo complesse.
 				
             </p>
             <p>
@@ -397,20 +397,20 @@
     }
 }
 ]]></php>
-				Questo collaudo \xE8 immune ai cambiamenti dello schema del db.
-				Fallisce solo se si rompono le funzionalit\xE0 dell'applicazione, cio\xE8
+				Questo collaudo è immune ai cambiamenti dello schema del db.
+				Fallisce solo se si rompono le funzionalità dell'applicazione, cioè
 				quello che intendevamo collaudare.
             </p>
             <p>
-				Il segreto \xE8 nel codice di <code>setUp()</code> e di <code>tearDown()</code>
+				Il segreto è nel codice di <code>setUp()</code> e di <code>tearDown()</code>
 				sui quali fino ad ora abbiamo sorvolato.
 				Questi metodi hanno il compito di ripulire le tabelle del database
 				ed assicurare la correttezza dello schema.
-				Realizzare questo risultato pu\xF2 comportare molto lavoro ma generalente 
+				Realizzare questo risultato può comportare molto lavoro ma generalente 
 				si dispone comunque di codice simile per svolgere il deployment.
             </p>
             <p>
-				Un'area dove si ha veramente bisogno del mocking \xE8 nella simulazione
+				Un'area dove si ha veramente bisogno del mocking è nella simulazione
 				delle anomalie.
 				Supponiamo che il database cada durante il funzionamento di <code>UserFinder</code>
                 
@@ -429,7 +429,7 @@
 }
 ]]></php>
 				E' stato passato un oggetto <code>$alert</code> a <code>UserFinder</code>.
-				Questo invier\xE0 alcuni messaggi all'interfaccia utente.
+				Questo invierà alcuni messaggi all'interfaccia utente.
 				Per poter passare il test, il finder, piuttostci che propagare 
 				un'eccezione, deve scrivere un messaggio a <code>$alert</code>.
                 				
@@ -444,29 +444,29 @@
 				Infine, cosa accade se il metodo che intendiamo simulare non esiste affatto?
 				Se si tenta di impostare un valore di ritorno su un metodo che non esiste,
 				SimpleTest lancia un'errore.
-				Perch\xE9 non usare <code>__call()</code> per simulare dinamicamente i metodi?
+				Perché non usare <code>__call()</code> per simulare dinamicamente i metodi?
             </p>
             <p>
 				L'uso di <code>__call</code> sugli oggetti con interfacce dinamiche
-				nella implementazione corrente dei mock pu\xF2 essere problematico.
-				E' possibile fare il mock del metodo <code>__call()</code> ma \xE8 una soluzione
+				nella implementazione corrente dei mock può essere problematico.
+				E' possibile fare il mock del metodo <code>__call()</code> ma è una soluzione
 				orrenda.
-				Perch\xE9 mail un test dovrebbe prendersi cura di tali dettagli di implementazione?
+				Perché mail un test dovrebbe prendersi cura di tali dettagli di implementazione?
 				Il test vuole solo simulare la chiamata.
             </p>
             <p>
-				La soluzione a questo \xE8 di aggiungere metodi extra al mock durante
+				La soluzione a questo è di aggiungere metodi extra al mock durante
 				la sua generazione.
 <php><![CDATA[
 <strong>Mock::generate('DatabaseConnection', 'MockDatabaseConnection', array('setOptions'));</strong>
 ]]></php>
-				In test suite di notevoli dimensioni questo pu\xF2 generare problemi, dal momento
-				che c'\xE8 il rischio di avere gi\xE0 una classe chiamata 
+				In test suite di notevoli dimensioni questo può generare problemi, dal momento
+				che c'è il rischio di avere già una classe chiamata 
                 <code>MockDatabaseConnection</code> priva dei metodi extra.
 				Il code generator infatti non genera la versione mock di una classe se ne
 				trova un'altra con lo stesso nome.
-				Vedere il proprio metodo fallire perch\xE9 un'altra definizione \xE8 stata
-				invocata precedentemente pu\xF2 essere disorientante.
+				Vedere il proprio metodo fallire perché un'altra definizione è stata
+				invocata precedentemente può essere disorientante.
             </p>
             <p>
 				Per gestire questa situazione, SimpleTest permette allo sviluppatore
@@ -480,19 +480,19 @@
             </p>
             <p>
 				Gli oggetti mock possono essere utilizzati solo all'interno dei test case
-				perch\xE9 inviano messaggi, come expectation, direttamente al test case.
+				perché inviano messaggi, come expectation, direttamente al test case.
                 Lanciarli al di fuori dell'ambiente del test case provocherebbe
 				un run time error non appena la prima expectation fosse invocata.
-				Parleremo delle expectation pi\xF9 avanti.
+				Parleremo delle expectation più avanti.
             </p>
         </section>
-        <section name="expectations" title="Mocks as critics">
+        <section name="expectations" title="Mock come critici">
             <p>
 				Nonostante l'approccio dei server stub riesca ad isolare i test
-				dagli sconvolgimenti del mondo, questa \xE8 solo una met\xE0 dei benefici.
+				dagli sconvolgimenti del mondo, questa è solo una metà dei benefici.
 				E' possibile fare in modo che la classe sotto collaudo riceva
 				i messaggi richiesti: ma si riesce a fargli inviare indietro quelli corretti?
-				Il collaudo pu\xF2 diventare un vero inferno senza una libreria di mocking.
+				Il collaudo può diventare un vero inferno senza una libreria di mocking.
             </p>
 			<p>
 				Per fare un esempio, consideriamo una semplice classe <code>PageController</code>
@@ -511,7 +511,7 @@
 				di ogni campo del form che non sia stato compilato correttamente.
             </p>
             <p>
-				Il metodo che ci interessa \xE8 <code>makePayment()</code>.
+				Il metodo che ci interessa è <code>makePayment()</code>.
 				Se viene inserito un numero &quot;CVV2&quot; errato (le ultime 3 cifre
 				sul retro della carta di credito) si vuole che il processo di pagamento non
 				venga nemmeno iniziato e che venga visualizzato invece un errore.
@@ -558,7 +558,7 @@
             <p>
 				Nel caso non si sia interessati al messaggio, come accade nel caso
 				di messaggi provenienti dall'interfaccia utente soggetti a molti cambiamenti,
-				\xE8 possibile saltare il parametro con l'operatore &quot;*&quot;:
+				è possibile saltare il parametro con l'operatore &quot;*&quot;:
 <php><![CDATA[
 class PaymentFormFailuresShouldBeGraceful extends UnitTestCase {
 
@@ -572,7 +572,7 @@
     function requestWithMissingCvv2() { ... }
 }
 ]]></php>
-				Possiamo rendere ancora pi\xF9 debole il test tralasciando l'array
+				Possiamo rendere ancora più debole il test tralasciando l'array
 				dei parametri:
 <php><![CDATA[
 function testMissingCvv2CausesAlert() {
@@ -582,21 +582,21 @@
     $controller->makePayment($this->requestWithMissingCvv2());
 }
 ]]></php>
-				In questo modo l'unico test che verr\xE0 effettuato \xE8 sull'invocazione
-				del metodo, il che pu\xF2 essere un po' eccessivo in questo caso.
-				Pi\xF9 avanti vedremo come indebolire le expectation in modo pi\xF9 selettivo.
+				In questo modo l'unico test che verrà effettuato è sull'invocazione
+				del metodo, il che può essere un po' eccessivo in questo caso.
+				Più avanti vedremo come indebolire le expectation in modo più selettivo.
             </p>
             <p>
 				I test senza assert sono sia compatti che molto espressivi.
 				Siccome la chiamata viene intercettata mentre arriva dall'interno dell'oggetto, in questo
-				caso della classe <code>Alert</code>, non c'\xE8 il bisogno di dichiarare alcun assert sul suo
+				caso della classe <code>Alert</code>, non c'è il bisogno di dichiarare alcun assert sul suo
 				stato.
-				Non solo questo evita gli assert nei test ma anche la necessit\xE0 di aggiungere
+				Non solo questo evita gli assert nei test ma anche la necessità di aggiungere
 				altri accessor al codice originale.
-                Nel caso ci si dovesse scoprire ad aggiungere accessor al codice, cio\xE8 quelli che
+                Nel caso ci si dovesse scoprire ad aggiungere accessor al codice, cioè quelli che
 				comunemente vengono chiamati &quot;state based testing&quot;, potrebbe essere il momento di
 				considerare l'uso dei mock nei propri test.
-				Quest'ultimo approccio \xE8 chiamato &quot;behaviour based testing&quot; ed \xE8 normalmente considerato
+				Quest'ultimo approccio è chiamato &quot;behaviour based testing&quot; ed è normalmente considerato
 				migliore rispetto all'uso degli accessor.
             </p>
             <p>
@@ -617,14 +617,14 @@
     ...
 }
 ]]></php>
-				Nei test pu\xF2 risultare molto difficile realizzare l'assert di una condizione negativa
+				Nei test può risultare molto difficile realizzare l'assert di una condizione negativa
 				ma il metodo <code>expectNever()</code> rende l'operazione semplice:
             </p>
             <p>
-                <code>expectOnce()</code> e <code>expectNever()</code> sono pi\xF9 che sufficienti
+                <code>expectOnce()</code> e <code>expectNever()</code> sono più che sufficienti
 				per la maggior parte dei test ma, occasionalmente, si potrebbe aver bisogno di
-				collaudare pi\xF9 eventi.
-				Normalmente, a vantaggio dell'usabilit\xE0, si vuole che vengano evidenziati  tutti i campi
+				collaudare più eventi.
+				Normalmente, a vantaggio dell'usabilità, si vuole che vengano evidenziati  tutti i campi
 				non compilati del form e non solo il primo.
 				Allo scopo dovremmo essere in grado di eseguire chiamate multiple
 				a <code>Alert::warn()</code> e non solo una:
@@ -644,18 +644,18 @@
 }
 ]]></php>
 				Il contatore presente in <code>expectAt()</code> rappresenta il numero
-				di volte per il quale il metodo \xE8 gi\xE0 stato invocato.
-				Qui si sta eseguendo un assert per ogni campo che verr\xE0 evidenziato.
+				di volte per il quale il metodo è già stato invocato.
+				Qui si sta eseguendo un assert per ogni campo che verrà evidenziato.
             </p>
             <p>
 				Si noti che siamo costretti a valutare anche l'ordine delle chiamate.
 				SimpleTest non prevede ancora un sistema per evitare questo inconveniente
-				ma lo preveder\xE0 nelle prossime versioni.
+				ma lo prevederà nelle prossime versioni.
             </p>
             <p>
-				Di seguito \xE8 riportato un elenco delle expectation utilizzabili su un
+				Di seguito è riportato un elenco delle expectation utilizzabili su un
 				oggetto mock in <a href="http://simpletest.org/">SimpleTest</a>.
-				Cos\xEC come per gli assert, questi metodi accettano un parametro opzionale
+				Così come per gli assert, questi metodi accettano un parametro opzionale
 				con il messaggio di failure.
                 <table>
                     <thead><tr><th>Expectation</th><th>Descrizione</th></tr></thead>
@@ -674,7 +674,7 @@
                         </tr>
                         <tr>
                             <td><code>expectMaximumCallCount($method, $count)</code></td>
-                            <td>Il metodo deve essere invocato non pi\xF9 di <code>$count</code> volte</td>
+                            <td>Il metodo deve essere invocato non più di <code>$count</code> volte</td>
                         </tr>
                         <tr>
                             <td><code>expectMinimumCallCount($method, $count)</code></td>
@@ -702,7 +702,7 @@
                     <dd>
 						L'elenco degli argomenti. E' possibile utilizzare i caratteri jolly allo
 						stesso modo in cui si utilizzano con <code>setReturn()</code>.
-                        Questo argomento \xE8 opzionale in <code>expectOnce()</code>
+                        Questo argomento è opzionale in <code>expectOnce()</code>
                         e in <code>expectAtLeastOnce()</code>.
                     </dd>
                     <dt class="new_code">$timing</dt>
@@ -716,19 +716,19 @@
                 </dl>
             </p>
             <p>
-				Nel caso si abbia una sola chiamata nel test, \xE8 bene assicurarsi
+				Nel caso si abbia una sola chiamata nel test, è bene assicurarsi
 				di usare <code>expectOnce</code>.<br />
                 L'uso di <code>$mocked->expectAt(0, 'method', 'args);</code>
 				consertirebbe al metodo di non essere mai invocato.
 				Il controllo degli argomenti ed il controllo del numero totale di chiamate 
 				sono operazioni indipendenti.
 				Quando si usa <code>expectAt()</code>, deve essere aggiunta la chiamata a <code>expectCallCount()</code> 
-				altrimenti risulter\xE0 consentito non invocare mai il metodo.
+				altrimenti risulterà consentito non invocare mai il metodo.
             </p>
             <p>
 				Come per gli assert nei test case, tutte le expectation accettano come terzo parametro un
 				messaggio con il quale sovrascrivere il messaggio di default.
-				Come nell'altro caso, inoltre, il messaggio di default pu\xF2 essere
+				Come nell'altro caso, inoltre, il messaggio di default può essere
 				recuperato mediante &quot;%s&quot;.
             </p>
         </section>

Modified: simpletest/trunk/docs/source/it/mock_objects_tutorial.xml
===================================================================
--- simpletest/trunk/docs/source/it/mock_objects_tutorial.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/mock_objects_tutorial.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,6 +1,6 @@
 <?xml version="1.0"?>
 <!-- $Id: mock_objects_tutorial.xml 1891 2009-07-26 12:32:26Z lastcraft $ -->
-<page title="Mock Objects" here="Using mock objects">
+<page title="Gli oggetti mock" here="Tutorial: gli oggetti mock">
     <long_title>PHP unit testing tutorial - Using mock objects in PHP</long_title>
     <content>
         <section name="refactor" title="Refactoring the tests again">

Modified: simpletest/trunk/docs/source/it/overview.xml
===================================================================
--- simpletest/trunk/docs/source/it/overview.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/overview.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,20 +1,20 @@
 <?xml version="1.0"?>
 <!-- $Id: overview.xml 1893 2009-07-26 13:52:26Z lastcraft $ -->
-<page title="Overview of SimpleTest" here="Overview">
+<page title="Panoramica su SimpleTest" here="Panoramica su SimpleTest">
     <long_title>
         Panoramica ed elenco delle caratteristiche dello unit tester e del web tester di SimpleTest
     </long_title>
     <content>
-        <section name="summary" title="What is SimpleTest?">
+        <section name="summary" title="Cos'è SimpleTest?">
             <p>
-                Il cuore di SimpleTest \xE8 un framework costruito intorno a classi
+                Il cuore di SimpleTest è un framework costruito intorno a classi
 				di test case. Queste ereditano delle classi test case di base
 				e vengono estese con dei metodi che contengono il codice di collaudo.
-                Ogni metodo di test di una classe test case \xE8 concepito per invocare
+                Ogni metodo di test di una classe test case è concepito per invocare
 				una serie di metodi assert, come <code>assertEqual()</code>, che lo sviluppatore
 				si attende vengano confermati.
                 Se il risultato atteso viene confermato allora successo dell'operazione
-				viene comunicato al test reporter che \xE8 in ascolto mentre qualsiasi
+				viene comunicato al test reporter che è in ascolto mentre qualsiasi
 				insuccesso o qualsiasi eccezione inattesa scatena un alert con la
 				relativa descrizione della discordanza.
 				
@@ -25,12 +25,12 @@
             </p>
             <p>
                 Nonostante i molti sforzi intrapresi per mantenere la
-				compatibilit\xE0 tra le varie versioni, la presente documentazione si riferisce 
+				compatibilità tra le varie versioni, la presente documentazione si riferisce 
 				alla versione 1.1 di SimpleTest.
 				
 				Nel caso si rilevi un malfunzionamento nei test dopo un aggiornamento,
 				si provi a consultare i file &quot;HELP_MY_TESTS_DONT_WORK_ANYMORE&quot; nella
-				directory simpletest per accertarsi della possibilit\xE0 che una delle feature che si stanno utilizzando
+				directory simpletest per accertarsi della possibilità che una delle feature che si stanno utilizzando
 				sia stata rimossa o indicata come deprecata.
             </p>
             <p>
@@ -52,44 +52,44 @@
 ]]></php>
             </p>
             <p>
-				SimpleTest \xE8 pensato per essere utilizzato da sviluppatori.
+				SimpleTest è pensato per essere utilizzato da sviluppatori.
                 I destinatari di questo tool includono tutti gli sviluppatori
 				di applicazioni PHP di medie dimensioni, compresi gli sviluppatori
 				che si sono avvicinati da poco all'argomento dello unit testing e del
 				web regression testing.
-                I principi cardine di SimpleTest sono la sua facilit\xE0 d'uso, l'estendibilit\xE0 e 
-				l'essenzialit\xE0 delle sue caratteristiche.
+                I principi cardine di SimpleTest sono la sua facilità d'uso, l'estendibilità e 
+				l'essenzialità delle sue caratteristiche.
             </p>
             <p>
-                I test vengono scritti direttamente in PHP, cio\xE8 nel linguaggio principale dell'applicazione.
+                I test vengono scritti direttamente in PHP, cioè nel linguaggio principale dell'applicazione.
 				Il vantaggio nell'uso del PHP come linguaggio di testing risiede nel
-				non dover imparare un nuovo linguaggio e nelle possibilit\xE0 di iniziare
+				non dover imparare un nuovo linguaggio e nelle possibilità di iniziare
 				immediatamente ad implementare i test e da permettere allo sviluppatore di 
 				collaudare uan qualsiasi parte del codice.
-				Fondamentalmente, qualsiasi sezione possa essere raggiunto dal codice dell'applicazione pu\xF2
+				Fondamentalmente, qualsiasi sezione possa essere raggiunto dal codice dell'applicazione può
 				essere anche raggiunta dal codice di test dal momento che entrambi utilizzano il
 				medesimo linguaggio di programmazione.
             </p>
             <p>
-				Il tipo pi\xF9 semplice di case test \xE8 lo 
+				Il tipo più semplice di case test è lo 
 				<a local="unit_tester_documentation">UnitTestCase</a>.
 				Questa classe comprende i test standard per valutare l'uguaglianza di valori e
 				riferimenti e il matching con pattern.
 				Tutti questi test eseguono delle verifiche sui valori attesi come ritorno di 
 				funzioni e metodi.
-				Si tratta senz'altro del tipo pi\xF9 comune di test nell'attivit\xE0 quotidiana di sviluppo
+				Si tratta senz'altro del tipo più comune di test nell'attività quotidiana di sviluppo
 				e costituiscono il 95% dei test case.
 				
                 
             </p>
             <p>
-				Tuttavia, l'obiettivo principale di un'applicazione web non \xE8 quello di
+				Tuttavia, l'obiettivo principale di un'applicazione web non è quello di
 				produrre gli output corretti dai suoi metodi e dai suoi oggetti ma quello
 				di generare pagine web.
 				La classe <a local="web_tester_documentation">WebTestCase</a> collauda le pagine web.
-                Simula l'attivit\xE0 di un browser che stia richiedendo una pagina e supporta cookie, proxy,
+                Simula l'attività di un browser che stia richiedendo una pagina e supporta cookie, proxy,
 				connessioni sicure, autenticazione, form, frame e molti altri elementi di navigazione.
-                Con questa tipologia di test case lo sviluppatore pu\xF2 verificare che le informazioni
+                Con questa tipologia di test case lo sviluppatore può verificare che le informazioni
 				presenti sulla pagina, sul form e nelle sessioni siano manipolate in modo corretto.
                 
             </p>
@@ -114,15 +114,15 @@
 ]]></php>
             </p>
         </section>
-        <section name="features" title="Feature list">
+        <section name="features" title="Elenco delle caratteristiche">
             <p>
-                Quanto segue \xE8 una grossolana panoramica delle caratteristiche esistenti e
+                Quanto segue è una grossolana panoramica delle caratteristiche esistenti e
 				pianificate per SimpleTest con l'indicazione del momento previsto per il loro rilascio.
-				C'\xE8 la possibilit\xE0 che questo elenco possa cambiare senza preavviso dal momento che
+				C'è la possibilità che questo elenco possa cambiare senza preavviso dal momento che
 				le milestone dipendono essenzialmente sul tempo libero che ho a disposizione.
-                Gli elementi colorati in verde sono gi\xE0 stati sviluppati ma non sono stati necessariamente
+                Gli elementi colorati in verde sono già stati sviluppati ma non sono stati necessariamente
 				rilasciati. Nel caso ci sia la particolare urgenza di accedere ad una
-				feature gi\xE0 svilupata ma non ancora rilasciata \xE8 possibile eseguire un checkout
+				feature già svilupata ma non ancora rilasciata è possibile eseguire un checkout
 				direttamente dal server SVN di Sourceforge.
                 <table><thead>
                     <tr><th>Feature</th><th>Descrizione</th><th>Release</th></tr>
@@ -133,7 +133,7 @@
                     </tr>
                     <tr>
                         <td>Reportistica Html</td>
-                        <td>Il tipo di visualizzazione pi\xF9 semplice</td>
+                        <td>Il tipo di visualizzazione più semplice</td>
                         <td style="color: green;">1.0</td>
                     </tr>
                     <tr>
@@ -161,7 +161,7 @@
                         <td>Mock parziali</td>
                         <td>
 							Eseguono il mocking di parte in una classe per permettere il
-							collaudo di elementi pi\xF9 piccoli di una classe e simulazioni
+							collaudo di elementi più piccoli di una classe e simulazioni
 							particolarmente complesse.
                         </td>
                         <td style="color: green;">1.0</td>
@@ -178,7 +178,7 @@
                     </tr>
                     <tr>
                         <td>Parsing dei form</td>
-                        <td>Capacit\xE0 di compilare semplici form e leggere i loro valori di default</td>
+                        <td>Capacità di compilare semplici form e leggere i loro valori di default</td>
                         <td style="color: green;">1.0</td>
                     </tr>
                     <tr>
@@ -202,7 +202,7 @@
                         <td>Browser component</td>
                         <td>
                             Espone un'interfaccia di basso livello per accedere al web browser ed eseguire
-							case test pi\xF9 dettagliati
+							case test più dettagliati
                         </td>
                         <td style="color: green;">1.0</td>
                     </tr>
@@ -259,7 +259,7 @@
                         <td style="color: green;">1.0.1</td>
                     </tr>
                     <tr>
-                        <td>Conformit\xE0 alla direttiva E_STRICT di PHP 5</td>
+                        <td>Conformità alla direttiva E_STRICT di PHP 5</td>
                         <td>Versione per PHP 5 in grado di funzionare con il livello di errore E_STRICT</td>
                         <td style="color: red;">1.1</td>
                     </tr>
@@ -280,7 +280,7 @@
                     </tr>
                     <tr>
                         <td>Fluent mock interface</td>
-                        <td>Oggetti mock ancora pi\xF9 flessibili e compatti</td>
+                        <td>Oggetti mock ancora più flessibili e compatti</td>
                         <td style="color: red;">1.6</td>
                     </tr>
                     <tr>
@@ -290,7 +290,7 @@
                     </tr>
                     <tr>
                         <td>Selettori CSS</td>
-                        <td>Il contenuto HTML generato pu\xF2 essere analizzato utilizzando i selettori CSS</td>
+                        <td>Il contenuto HTML generato può essere analizzato utilizzando i selettori CSS</td>
                         <td style="color: red;">1.7</td>
                     </tr>
                     <tr>
@@ -325,7 +325,7 @@
                     </tr>
                     <tr>
                         <td>Vecchi metodi segnati come deprecati</td>
-                        <td>SimpleTest2 possiede un'interfaccia pi\xF9 semplice</td>
+                        <td>SimpleTest2 possiede un'interfaccia più semplice</td>
                         <td style="color: red;">2.0</td>
                     </tr>
                     <tr>
@@ -334,8 +334,8 @@
                         <td style="color: red;">3.0</td>
                     </tr>
                 </tbody></table>
-				L'integrazione con PHP 5 \xE8 completa il che significa che a partire dalla
-				versione 1.1 di SimpleTest verr\xE0 supportato solo PHP versione 5.0.5 o superiore.
+				L'integrazione con PHP 5 è completa il che significa che a partire dalla
+				versione 1.1 di SimpleTest verrà supportato solo PHP versione 5.0.5 o superiore.
                 Le precedenti versioni di SimpleTest sono compatibili con PHP dalla versione 4.2
 				alla versione 5 (non E_STRICT).
             </p>
@@ -405,4 +405,4 @@
             </author>
         </authorgroup>
     </refsynopsisdiv>
-</page>
+</page>
\ No newline at end of file

Modified: simpletest/trunk/docs/source/it/partial_mocks_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/partial_mocks_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/partial_mocks_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,34 +1,34 @@
 <?xml version="1.0"?>
 <!-- $Id: partial_mocks_documentation.xml 1874 2009-06-12 16:17:51Z pp11 $ -->
-<page title="Partial mock objects documentation" here="Partial mocks">
+<page title="Il mocking parziale" here="Il mocking parziale">
     <long_title>SimpleTest for PHP partial mocks documentation</long_title>
     <content>
         <introduction>
             <p>
-				Il mocking parziale non \xE8 nient'altro che un pattern per facilitare la
+				Il mocking parziale non è nient'altro che un pattern per facilitare la
 				risoluzione di alcuni problemi specifici che si incontrano nel collaudo con oggetti mock
 				e in cui l'uso degli oggetti mock diviene assai difficoltoso.
-				Si tratta di un tool abbastanza limitato e probabilmente non \xE8 nemmeno
+				Si tratta di un tool abbastanza limitato e probabilmente non è nemmeno
 				un'idea brillante.
-				E' stato incluso comunque in SimpleTest perch\xE9 l'ho personalmente trovato
-				utile in pi\xF9 occasioni e mi ha permesso di risparmiare molto tempo..
+				E' stato incluso comunque in SimpleTest perché l'ho personalmente trovato
+				utile in più occasioni e mi ha permesso di risparmiare molto tempo..
             </p>
         </introduction>
-        <section name="inject" title="The mock injection problem">
+        <section name="inject" title="Il problema del Mock Injection">
             <p>
-				Quando un oggetto ne uso un altro \xE8 semplicissimo passarli una versione mock
-				gi\xE0 decorata con le sue expectation.
-				Le cose diventano molto pi\xF9 complicate quando \xE8 un oggetto ne crea un altro
-				e l'oggetto creatore \xE8 quello che si deve collaudare.
-				Questo significa che \xE8 l'oggetto creato che dovrebbe essere sostituito dalla
-				versione mock: ma pu\xF2 essere difficile impartire alla classe sotto test l'ordine
+				Quando un oggetto ne uso un altro è semplicissimo passarli una versione mock
+				già decorata con le sue expectation.
+				Le cose diventano molto più complicate quando è un oggetto ne crea un altro
+				e l'oggetto creatore è quello che si deve collaudare.
+				Questo significa che è l'oggetto creato che dovrebbe essere sostituito dalla
+				versione mock: ma può essere difficile impartire alla classe sotto test l'ordine
 				di creare una versione mock invece dell'originale.
 				Del resto, la classe sotto test nemmeno dovrebbe essere a conoscenza
 				di essere eseguita all'interno di un test.
             </p>
             <p>
 				Per esempio, supponiamo che si stia scrivendo un client telnet e
-				che ci sia la necessit\xE0 di creare un socket a cui passare i messaggi.
+				che ci sia la necessità di creare un socket a cui passare i messaggi.
 				Il metodo di connessione potrebbe avere un aspetto simile a questo:
 <php><![CDATA[
 <strong><?php
@@ -47,13 +47,13 @@
 				Se volessimo avere una versione mock del socket, cosa si potrebbe fare?
             </p>
             <p>
-				La prima soluzione \xE8 quella di passare il socket come parametro,
+				La prima soluzione è quella di passare il socket come parametro,
 				in mododi forzare la creazione al livello superiore.
-				Il fatto che sia il client a dover gestire la creazione \xE8 un buon approccio
-				se si \xE8 disposti a gestire la cosa e dovrebbe spingere verso una
+				Il fatto che sia il client a dover gestire la creazione è un buon approccio
+				se si è disposti a gestire la cosa e dovrebbe spingere verso una
 				fattorizazione della creazione.
-                Difatti, questo \xE8 uno dei sistemi con i quali il test con i mock object
-				costringono lo sviluppatore a sviluppare adottando soluzioni pi\xF9 rigorose.
+                Difatti, questo è uno dei sistemi con i quali il test con i mock object
+				costringono lo sviluppatore a sviluppare adottando soluzioni più rigorose.
                 I mock migliorano lo stile di programmazione.
             </p>
             <p>
@@ -71,7 +71,7 @@
 }
 ?>
 ]]></php>
-                Ci\xF2 significa che il codice di test si riduce all'invocazione
+                Ciò significa che il codice di test si riduce all'invocazione
 				tipica degli oggetti mock:
 <php><![CDATA[
 class TelnetTest extends UnitTestCase {
@@ -85,14 +85,14 @@
     }
 }
 ]]></php>
-				E' abbastanza evidente, tuttavia, che un unico livello \xE8 tutto quello che
-				ci si pu\xF2 aspettare di ottenere. Difficilmente accetteremo che l'applicazione
+				E' abbastanza evidente, tuttavia, che un unico livello è tutto quello che
+				ci si può aspettare di ottenere. Difficilmente accetteremo che l'applicazione
 				stessa debba preoccuparsi della creazione di socket, connessione al database
 				ed altri oggetti necessari ai livelli sottostanti.
 				Sarebbe difficile anche conoscere i parametri necessari ai costruttori.
             </p>
             <p>
-				Un possibilecompromesso \xE8 quello di prevedere l'oggetto istanziato come
+				Un possibilecompromesso è quello di prevedere l'oggetto istanziato come
 				parametro opzionale:
 <php><![CDATA[
 <?php
@@ -111,7 +111,7 @@
 }
 ?>
 ]]></php>
-				Come soluzione di emergenza questo pu\xF2 anche andare bene.
+				Come soluzione di emergenza questo può anche andare bene.
 				Adesso il test funziona come se il parametro fosse formalmente
 				passato:
 <php><![CDATA[
@@ -126,15 +126,15 @@
     }
 }
 ]]></php>
-				Il problema di questo approccio \xE8 nel disordine che
+				Il problema di questo approccio è nel disordine che
 				genera.
-				Nella classe principale c'\xE8 del codice di test e nel codice di test
+				Nella classe principale c'è del codice di test e nel codice di test
 				ci sono dei paramtri che non vengono mai utilizzati.
-				E' un approccio veloce e sporco, ma nonostante tutto pu\xF2 essere
+				E' un approccio veloce e sporco, ma nonostante tutto può essere
 				efficace in molte situazioni.
             </p>
             <p>
-				Un'ulteriore soluzione \xE8 quella di passare un oggetto factory a cui
+				Un'ulteriore soluzione è quella di passare un oggetto factory a cui
 				demandare la creazione:
 <php><![CDATA[
 <?php
@@ -154,10 +154,10 @@
 }
 ?>
 ]]></php>
-				Questa \xE8 probabilmente la soluzione pi\xF9 fattorizzata dal momento che
-				la creazione degli oggetti \xE8 stata spostata all'interno di una
+				Questa è probabilmente la soluzione più fattorizzata dal momento che
+				la creazione degli oggetti è stata spostata all'interno di una
 				piccola classe specializzata.
-				Adesso il factory della rete pu\xF2 essere collaudato separatamente dal
+				Adesso il factory della rete può essere collaudato separatamente dal
 				resto ma risulta anche semplice crearne un mock nel momento del collaudo
 				della classe telnet:
 <php><![CDATA[
@@ -174,18 +174,18 @@
     }
 }
 ]]></php>
-				Il rovescio della medaglia \xE8 che si sono aggiunte molte classi
+				Il rovescio della medaglia è che si sono aggiunte molte classi
 				alla libreria e che si stanno passando molte classi factory in qua
-				e l\xE0 ed il codice diventa un po' meno intuitivo.
-				Questa \xE8 la soluzione pi\xF9 flessibile ma anche la pi\xF9 complessa.
+				e là ed il codice diventa un po' meno intuitivo.
+				Questa è la soluzione più flessibile ma anche la più complessa.
             </p>
             <p>
                 Esiste una via di mezzo?
             </p>
         </section>
-        <section name="creation" title="Protected factory method">
+        <section name="creation" title="Il pattern Protected Factory">
             <p>
-                Esiste un sistema con cui \xE8 possibile circoscrivere il problema
+                Esiste un sistema con cui è possibile circoscrivere il problema
 				senza creare nuove classi ma prevede l'utilizzo di una sottoclasse
 				della classe originale nel test.
 				Intanto, spostiamo la creazione del socket in un metodo dedicato:
@@ -207,7 +207,7 @@
 }
 ?>
 ]]></php>
-				Questo \xE8 l'unico cambiamento richiesto al codice dell'applicazione.
+				Questo è l'unico cambiamento richiesto al codice dell'applicazione.
             </p>
             <p>
 				Nel test case si deve creare una sottoclasse in modo da poter
@@ -226,12 +226,12 @@
     }
 }</strong>
 ]]></php>
-				Qui il mock \xE8 stato passato al costruttore ma un
+				Qui il mock è stato passato al costruttore ma un
 				ordinario metodo setter avrebbe svolto ugualmente il
 				medesimo compito.
-                Si noti come il mock \xE8 stato iniettato dentro l'oggetto
+                Si noti come il mock è stato iniettato dentro l'oggetto
 				prima della chiamata del costruttore.
-				Questo \xE8 necessario nel caso il costruttore faccia
+				Questo è necessario nel caso il costruttore faccia
 				chiamate a <code>connect()</code>. In caso
 				contrario <code>_createSocket()</code> avrebbe restituito 
 				al costruttore un valore nullo
@@ -239,7 +239,7 @@
             </p>
             <p>
 				Dopo il completamento di tutto questo lavoro extra,
-				il test in se' \xE8 diascretamente pi\xF9 semplice.
+				il test in se' è diascretamente più semplice.
 				E' sufficiente colaudare la nuova classe invece di
 				quella originale:
 <php><![CDATA[
@@ -254,24 +254,24 @@
     }
 }
 ]]></php>
-                La nuova classe, naturalmente, \xE8 molto semplice.
-				Semplicemente imposter\xE0 un valore di ritorno, come un mock.
+                La nuova classe, naturalmente, è molto semplice.
+				Semplicemente imposterà un valore di ritorno, come un mock.
 				Sarebbe bello se, oltre a questo, verificasse anche i parametri 
 				ricevuti. Proprio come un mock.
 				Visto che sembra useremo spesso questa tecnica,
 				possiamo automatizzare la creazione della sottoclasse?
             </p>
         </section>
-        <section name="partial" title="A partial mock">
+        <section name="partial" title="Un mock parziale">
             <p>
-				Naturalmente la risposta \xE8 &quot;s\xEC&quot;, altrimenti avrei smesso di 
+				Naturalmente la risposta è &quot;sì&quot;, altrimenti avrei smesso di 
 				scrivere da un pezzo!
 				L'ultimo test che abbiamo scritto ha comportato un bel po' di lavoro
 				ma si potrebbe utilizzare un approccio simile alla generazione
 				degli oggetti mock per creare la sottoclasse.
             </p>
             <p>
-                Questa \xE8 la versione del test con il mocking parziale:
+                Questa è la versione del test con il mocking parziale:
 <php><![CDATA[
 <strong>Mock::generatePartial(
         'Telnet',
@@ -291,7 +291,7 @@
     }
 }
 ]]></php>
-				Il mock parziale \xE8 una sottoclasse della classe originale
+				Il mock parziale è una sottoclasse della classe originale
 				nella quale alcuni metodi sono sostituiti con
 				versioni di test.
                 <code>generatePartial()</code> accetta tre parametri: la
@@ -299,20 +299,20 @@
 				un elenco dei metodi da sostituire.
             </p>
             <p>
-				Il modo di istanziare gli oggetti risultati \xE8 un po' delicato.
+				Il modo di istanziare gli oggetti risultati è un po' delicato.
 				L'unico parametro atteso dal costruttore di un mock parziale
-				\xE8 un riferimento allo unit test. Cos\xEC come gli ordinari oggetti
-				mock, infatti, questo \xE8 necesssario affinch\xE9 l'oggetto possa restituire
+				è un riferimento allo unit test. Così come gli ordinari oggetti
+				mock, infatti, questo è necesssario affinché l'oggetto possa restituire
 				i risultati delle expectation valutate.
             </p>
             <p>
-				Il costruttore originale non \xE8 stato ancora invocato.
-				E' necessario rimandare la sua invocazione perch\xE9
+				Il costruttore originale non è stato ancora invocato.
+				E' necessario rimandare la sua invocazione perché
 				potrebbe fare uso di uno dei metodi sostituiti ancora non
 				impostati.
 				Si impostano quindi i valori di ritorno e solo a questo punto
 				si invoca il costruttore con i suoi parametri.
-                Quello che distingue i mock parziali dai mock ordinari \xE8 la
+                Quello che distingue i mock parziali dai mock ordinari è la
 				successione di questi tre passi: costruzione con &quot;new&quot;,
 				impostazione dei metodi, invocazione del costruttore vero e proprio.
             </p>
@@ -339,28 +339,28 @@
 ]]></php>
             </p>
         </section>
-        <section name="less" title="Testing less than a class">
+        <section name="less" title="Collaudare meno di una classe">
             <p>
-				Non \xE8 necessario che i metodi sostituiti siano metodi factory: \xE8 possibile
+				Non è necessario che i metodi sostituiti siano metodi factory: è possibile
 				sostituire qualsiasi tipologia di metodo.
-				Questo \xE8 il modo in cui i mock parziali permettono di prendere
+				Questo è il modo in cui i mock parziali permettono di prendere
 				il controllo di qualsiasi parte di una classe, eslcuso il costruttore.
 				Sarebbe perfino possibile sostituire tutti i metodi tranne
 				l'unico da collaudare.
             </p>
             <p>
-				Quest'ultima situazione \xE8 piuttosto ipotetica dal momento che
+				Quest'ultima situazione è piuttosto ipotetica dal momento che
 				non l'ho mai provata.
 				Posso anche credere che questo funzioni ma sono convinto che
-				forzando la granularit\xE0 dell'oggetto non si ottengano necessariamente un
-				codice di qualit\xE0 migliore.
+				forzando la granularità dell'oggetto non si ottengano necessariamente un
+				codice di qualità migliore.
 				Personalmente utilizzo il mocking parziale come un sistema per
 				l'override della creazione di oggetti o per l'occasionale test
 				di oggetti che implementino il design TemplateMethod.
             </p>
             <p>
-                Quale meccanismo utilizzare, alla fine, \xE8 una questione legata allo standard che
-				si \xE8 scelto per i propri progetti.
+                Quale meccanismo utilizzare, alla fine, è una questione legata allo standard che
+				si è scelto per i propri progetti.
             </p>
         </section>
     </content>

Modified: simpletest/trunk/docs/source/it/reporter_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/reporter_documentation.xml	2009-09-08 15:10:43 UTC (rev 1950)
+++ simpletest/trunk/docs/source/it/reporter_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
@@ -1,48 +1,47 @@
 <?xml version="1.0"?>
 <!-- $Id: reporter_documentation.xml 1878 2009-06-12 16:39:37Z pp11 $ -->
-<page title="Test reporter documentation" here="Reporting">
+<page title="I report" here="I report">
     <long_title>SimpleTest for PHP test runner and display documentation</long_title>
     <content>
         <introduction>
             <p>
-                SimpleTest pretty much follows the MVC pattern
+				SimpleTest abbraccia abbastanza fedelmente il pattern MVC
                 (Model-View-Controller).
-                The reporter classes are the view and the model is your
-                test cases and their hiearchy.
-                The controller is mostly hidden from the user of
-                SimpleTest unless you want to change how the test cases
-                are actually run, in which case it is possible to
-                override the runner objects from within the test case.
-                As usual with MVC, the controller is mostly undefined
-                and there are other places to control the test run.
+				Le classi reporter sono le viste mentre i test case e le loro
+				gerarchie sono i modelli.
+				I controller sono per lo più nascosti all'utente di SimpleTest a
+				meno che si voglia modificare il meccanismo di esecuzione dei
+				test, nel qual caso risulta possibile sovrascivere l'oggetto
+				in esecuzione dall'interno del test case.
+				Come accade di solito con l'MVC, il controller e per lo più
+				vuoto e si controlla l'esecuzione del test da altri posti.
             </p>
         </introduction>
-        <section name="html" title="Reporting results in HTML">
+        <section name="html" title="Visualizzare i report in HTML">
             <p>
-                The default test display is minimal in the extreme.
-                It reports success and failure with the conventional red and
-                green bars and shows a breadcrumb trail of test groups
-                for every failed assertion.
-                Here&apos;s a fail...
+				Il sistema di visualizzazione standard è minimale.
+                Si limita a riportare successi e fallimenti con le convenzionali
+				barre verdi e rosse e mostra un percorso (breadcrumb) dei gruppi di test
+				per ogni assert fallito.
+                Un esempio di test fallito è:
                 <div class="demo">
                     <h1>File test</h1>
                     <span class="fail">Fail</span>: createnewfile->True assertion failed.<br />
                     <div style="padding: 8px; margin-top: 1em; background-color: red; color: white;">1/1 test cases complete.
                     <strong>0</strong> passes, <strong>1</strong> fails and <strong>0</strong> exceptions.</div>
                 </div>
-                And here all tests passed...
+                Questo è il caso in cui tutti i test siano usciti con successo:
                 <div class="demo">
                     <h1>File test</h1>
                     <div style="padding: 8px; margin-top: 1em; background-color: green; color: white;">1/1 test cases complete.
                     <strong>1</strong> passes, <strong>0</strong> fails and <strong>0</strong> exceptions.</div>
                 </div>
-                The good news is that there are several points in the display
-                hiearchy for subclassing.
+				La buona notizia è che esistono molte classi della gerarchia del
+				reporter da cui poter ereditare:
             </p>
             <p>
-                For web page based displays there is the
-                <code>HtmlReporter</code> class with the following
-                signature...
+				Per la visualizzazione su pagine web si può usare la classe
+                <code>HtmlReporter</code> che ha la seguente interfaccia:
 <php><![CDATA[
 class HtmlReporter extends SimpleReporter {
     public HtmlReporter($encoding) { ... }
@@ -71,120 +70,125 @@
     public integer getTestCaseProgress() { ... }
 }
 ]]></php>
-                Here is what some of these methods mean. First the display methods
-                that you will probably want to override...
+                Di seguito si riporta il significato dei vari metodi. Sono stati riportati
+				prima i metodi di visualizzazione dal momento che sono quelli che normalmente
+				si vuole riscrivere:
                 <ul class="api">
                     <li>
                         <code>HtmlReporter(string $encoding)</code><br />
-                        is the constructor.
-                        Note that the unit test sets up the link to the display
-                        rather than the other way around.
-                        The display is a mostly passive receiver of test events.
-                        This allows easy adaption of the display for other test
-                        systems beside unit tests, such as monitoring servers.
-                        The encoding is the character encoding you wish to
-                        display the test output in.
-                        In order to correctly render debug output when
-                        using the web tester, this should match the encoding
-                        of the site you are trying to test.
-                        The available character set strings are described in
-                        the PHP <a href="http://www.php.net/manual/en/function.htmlentities.php">html_entities()</a>
-                        function.
+                        è il costruttore.
+						Si noti che è lo unit test a conservare un riferimento
+						al reporter, e non il contrario.
+						Il reporter è sostanzialmente un ricevitore passivo di
+						eventi di test.
+                        Questo garantisce un facile adattamento del display ad altri
+						sistemi di test diversi dagli unit test, come ad esempio i
+						server di monitoraggio.
+						L'encoding è il sistema di codifica di caratteri che si vuole
+						venga usato nella visualizzazione dei report.
+						Per garantire che i messaggi di debug vengano visualizzati
+						correttamento durante il web testing, ci si dovrebbe assicurare
+						che la codifica dei caratteri coincida con quella usata nel sito
+						che si sta collaudando.
+						Le stringhe corrispondenti alle codifiche carattere sono
+						descritte nella documentazione della funzione 
+                        <a href="http://www.php.net/manual/en/function.htmlentities.php">html_entities()</a>.
                     </li>
                     <li>
                         <code>void paintHeader(string $test_name)</code><br />
-                        is called once at the very start of the test when the first
-                        start event arrives.
-                        The first start event is usually delivered by the top level group
-                        test and so this is where <code>$test_name</code>
-                        comes from.
-                        It paints the page titles, CSS, body tag, etc.
-                        It returns nothing (<code>void</code>).
+                        E' invocata all'inizio dei test non appena viene ricevuto
+						il primo evento di inizio test.
+						L'evento di inizio test è normalmente generato dal primo gruppo di test
+						ed è questo che fornisce <code>$test_name</code>.
+                        Questo metodo visualizza il titolo della pagina, i CSS, il tag body e così via.
+						Non restituisce niente.
                     </li>
                     <li>
                         <code>void paintFooter(string $test_name)</code><br />
-                        Called at the very end of the test to close any tags opened
-                        by the page header.
-                        By default it also displays the red/green bar and the final
-                        count of results.
-                        Actually the end of the test happens when a test end event
-                        comes in with the same name as the one that started it all
-                        at the same level.
-                        The tests nest you see.
-                        Closing the last test finishes the display.
+                        Viene invocato al termine del test e si preoccupa di chiudere
+						qualsiasi tag sia stato aperto dall'header della pagina.
+						Di default, mostra anche le barre verdi e rosse e il conteggio
+						finale dei risultati.
+						Per essere più precisi, la fine dei test è individuata dalla ricezione
+						di un evento di fine test avente lo stesso nome del test con il quale
+						si è iniziato l'intero processo al medesimo livello. I test, infatti,
+						possono essere annidati.
+						La chiusura dell'ultimo test fa terminare il display.
                     </li>
                     <li>
                         <code>void paintMethodStart(string $test_name)</code><br />
-                        is called at the start of each test method.
-                        The name normally comes from method name.
-                        The other test start events behave the same way except
-                        that the group test one tells the reporter how large
-                        it is in number of held test cases.
-                        This is so that the reporter can display a progress bar
-                        as the runner churns through the test cases.
+						Viene invocato all'inizio di ciascun metodo di test.
+						Il nome, normalmente, coincide con il nome del metodo.
+						Gli altri eventi di inizio test producono il medesimo comportamento
+						tranne per il fatto che il primo gruppo di test comunica al reporter
+						il numero di test case che contiene.
+						In questo modo il reporter può essere in grado di visualizzare
+						una barra di progressione mentre il motore macina i test case.
                     </li>
                     <li>
                         <code>void paintMethodEnd(string $test_name)</code><br />
-                        backs out of the test started with the same name.
+						resti
+                        termina il test che era stato iniziato con il medesimo nome.
                     </li>
                     <li>
                         <code>void paintFail(string $message)</code><br />
-                        paints a failure.
-                        By default it just displays the word fail, a breadcrumbs trail
-                        showing the current test nesting and the message issued by
-                        the assertion.
+                        visualizza una failure.
+						Il comportamento standard è quello di visualizzare la parola fail, un
+						indicatore della progressione indicante il test annidato ed il messaggio
+						riportato dall'assert.
                     </li>
                     <li>
                         <code>void paintPass(string $message)</code><br />
-                        by default does nothing.
+                        Di default non fa niente.
                     </li>
                     <li>
                         <code>string getCss()</code><br />
-                        Returns the CSS styles as a string for the page header
-                        method.
-                        Additional styles have to be appended here if you are
-                        not overriding the page header.
-                        You will want to use this method in an overriden page header
-                        if you want to include the original CSS.
+						restituisce gli stili CSS come un'unica striga per il metodo
+						dell'header della pagina.
+						Gli stili addizionali possono essere appesi qui a meno che
+						non si voglia fare l'overriding dell'header della pagina.
+						Se si è sovrascritto il page header, si può richiamare questo metodo per recuperare
+						il CSS originale.
                     </li>
                 </ul>
-                There are also some accessors to get information on the current
-                state of the test suite.
-                Use these to enrich the display...
+				Ci sono a disposizione anche alcuni metodi get che permettono di
+				recuperare informazioni sullo stato corrente della test suite.
+				Si utilizzano per arricchire la visualizzazione:
                 <ul class="api">
                     <li>
                         <code>array getTestList()</code><br />
-                        is the first convenience method for subclasses.
-                        Lists the current nesting of the tests as a list
-                        of test names.
-                        The first, most deeply nested test, is first in the
-                        list and the current test method will be last.
+                        è il primo metodo di appoggio per il subclassing.
+						Restituisce l'attuale struttura annidata dei test come un
+						elenco di nomi di test.
+                        Il test più profondamente annidato risulterà il primo
+						dell'elenco e il metodo correntemente eseguito l'ultimo.
                     </li>
                     <li>
                         <code>integer getPassCount()</code><br />
-                        returns the number of passes chalked up so far.
-                        Needed for the display at the end.
+                        restituisce il numero di passi eseguiti.
+						E' necessario per chiudere la visualizzazione.
                     </li>
                     <li>
                         <code>integer getFailCount()</code><br />
-                        is likewise the number of fails so far.
+						restituisce, analogamente, il numero dei fallimenti.
                     </li>
                     <li>
                         <code>integer getExceptionCount()</code><br />
-                        is likewise the number of errors so far.
+						Similmente a sopra, restituisce il numero delle eccezioni.
                     </li>
                     <li>
                         <code>integer getTestCaseCount()</code><br />
-                        is the total number of test cases in the test run.
-                        This includes the grouping tests themselves.
+						Restituisce il numero dei test case totale.
+						Il conteggio include anche i gruppi di test.
                     </li>
                     <li>
                         <code>integer getTestCaseProgress()</code><br />
-                        is the number of test cases completed so far.
+						Restituisce il numero di test completati.
                     </li>
                 </ul>
-                One simple modification is to get the HtmlReporter to display
-                the passes as well as the failures and errors...
+				Una delle modifiche semplici da effettuare è quella di fare in modo
+				che HtmlReported visualizzi anche i normali passi oltre che agli errori
+				e alle failure:
 <php><![CDATA[
 <strong>class ShowPasses extends HtmlReporter {
     
@@ -204,38 +208,33 @@
 ]]></php>
             </p>
             <p>
-                One method that was glossed over was the <code>makeDry()</code>
-                method.
-                If you run this method, with no parameters, on the reporter
-                before the test suite is run no actual test methods
-                will be called.
-                You will still get the events of entering and leaving the
-                test methods and test cases, but no passes or failures etc,
-                because the test code will not actually be executed.
+				Un metodo sul quale si è sorvolato è <code>makeDry()</code>.
+				Quando viene invocato senza parametri prima del lancio dei test,
+				la sua esecuzione inibisce l'avvio dei test.
+				Tuttavia, si continueranno a ricevere gli eventi di inizio e fine dei
+				test e dei test case, ma nessun evento di successo o fallimento, poichè
+				il codice dei test non verrà fisicamente eseguito.d.
             </p>
             <p>
-                The reason for this is to allow for more sophistcated
-                GUI displays that allow the selection of individual test
-                cases.
-                In order to build a list of possible tests they need a
-                report on the test structure for drawing, say a tree view
-                of the test suite.
-                With a reporter set to dry run that just sends drawing events
-                this is easily accomplished.
+				Il motivo per cui esiste un tale metodo è legato alla possibilità
+				di costruire GUI particolarmente sofisticate che permettano di
+				selezionare individualmente i case test.
+				Con un reporter impostato in dry run cge unvia solo eventi di visualizzazione
+				questo è facilmente ottenibile.
             </p>
         </section>
-        <section name="other" title="Extending the reporter">
+        <section name="other" title="Visualizzare i risultati in altri formati">
             <p>
-                Rather than simply modifying the existing display, you might want to
-                produce a whole new HTML look, or even generate text or XML.
-                Rather than override every method in
-                <code>HtmlReporter</code> we can take one
-                step up the class hiearchy to <code>SimpleReporter</code>
-                in the <em>simple_test.php</em> source file.
+				Piuttosto che modificare il display esistente si potrebbe desiderare
+				di produrre un HTML completamente diverso o perfino generare un
+				output testuale o in XML.
+				Piuttosto che sovrascrivere ogni singolo metodi in, è possibile
+				salire di un passo nella gerarchia delle classi ed estendere direttamente
+				<code>SimpleReporter</code> dsel file <em>simple_test.php</em>.
             </p>
             <p>
-                A do nothing display, a blank canvas for your own creation, would
-                be...
+				Un esempio di display che non fa niente se non mostrare una pagina
+				bianca potrebbe essere:
 <php><![CDATA[
 <strong>require_once('simpletest/simple_test.php');</strong>
 
@@ -264,16 +263,17 @@
     }
 }
 ]]></php>
-                No output would come from this class until you add it.
+				Finché non si definisce un output questa classe non ne produrrà alcuno.
             </p>
         </section>
-        <section name="cli" title="The command line reporter">
+        <section name="cli" title="Usare SimpleTest dalla riga di comando">
             <p>
-                SimpleTest also ships with a minimal command line reporter.
-                The interface mimics JUnit to some extent, but paints the
-                failure messages as they arrive.
-                To use the command line reporter simply substitute it
-                for the HTML version...
+				SimpleTest è provvisto anche di un reporter minimale a riga di comando.
+				L'interfaccia, fino ad un certo punto, imita quella di JUnit ma
+				a differenza di questo visualizza i messaggi di failure non appena vengono
+				ricevuti.
+				Per utilizzare il reporter a riga di comando è sufficiente sostituirla
+				a quella HTML:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -283,19 +283,18 @@
 $test->run(<strong>new TextReporter()</strong>);
 ?>
 ]]></php>
-                Then invoke the test suite from the command line...
+				Dopo di che, si invoca la test suite dalla command line:
 <pre class="shell">
 php file_test.php
 </pre>
-                You will need the command line version of PHP installed
-                of course.
-                A passing test suite looks like this...
+				Naturalmente, ci sarà bisogno della versione CLI di PHP.
+				Un test passato con successo assomiglierà a:
 <pre class="shell">
 File test
 OK
 Test cases run: 1/1, Failures: 0, Exceptions: 0
 </pre>
-                A failure triggers a display like this...
+                Un test fallito, invece, visualizzerà:
 <pre class="shell">
 File test
 1) True assertion failed.
@@ -305,16 +304,14 @@
 </pre>
             </p>
             <p>
-                One of the main reasons for using a command line driven
-                test suite is of using the tester as part of some automated
-                process.
-                To function properly in shell scripts the test script should
-                return a non-zero exit code on failure.
-                If a test suite fails the value <code>false</code>
-                is returned from the <code>SimpleTest::run()</code>
-                method.
-                We can use that result to exit the script with the desired return
-                code...
+				Uno dei motivi per cui si può desiderare di usare una test suite
+				a linea di comando è per l'integrazione del tester all'intero di qualche
+				processo automatizzato.
+				Per un funzionamento corretto negli script shell, il test dovrebbe
+				restituire un codice diverso di zero in caso di fallimento.
+				Quando una test suite fallisce, il metodo <code>SimpleTest::run()</code>
+				restituisce <code>false</code>. E' possibile usaere questo risultato
+				per far produrre allo script l'adeguato codice di uscita:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -324,10 +321,10 @@
 <strong>exit ($test->run(new TextReporter()) ? 0 : 1);</strong>
 ?>
 ]]></php>
-                Of course we don&apos;t really want to create two test scripts,
-                a command line one and a web browser one, for each test suite.
-                The command line reporter includes a method to sniff out the
-                run time environment...
+				Ovviamente, non si vuole dover scrivere davvero due script di test
+				separati per ogni test suite, uno per la riga di comando ed uno per il browser.
+                Per questo, il reporter a riga di comando include un metodo per 
+				intercettare l'ambiente di runtime:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');
@@ -340,14 +337,14 @@
 $test->run(new HtmlReporter());
 ?>
 ]]></php>
-                This is the form used within SimpleTest itself.
+				Questo è il sistema usato dentro SimpleTest stesso.
             </p>
         </section>
-        <section name="xml" title="Remote testing">
+        <section name="xml" title="Usare l'XML per i collaudi in remoto">
             <p>
-                SimpleTest ships with an <code>XmlReporter</code> class
-                used for internal communication.
-                When run the output looks like...
+				SimpleTest viene fornito con una classe <code>XmlReporter</code>
+				utilizzata per comunicazioni interne.
+				Quando viene eseguita, produce un output di questo tipo:
 <pre class="shell"><![CDATA[
 <?xml version="1.0"?>
 <run>
@@ -370,10 +367,10 @@
   </group>
 </run>
 ]]></pre>
-                You can make use of this format with the parser
-                supplied as part of SimpleTest itself.
-                This is called <code>SimpleTestXmlParser</code> and
-                resides in <em>xml.php</em> within the SimpleTest package...
+				E' possibile utilizzare questo formato con il
+				parser di cui è provvisto SimpleTest, chiamato
+				<code>SimpleTestXmlParser</code> e memorizzato nel file
+				<em>xml.php</em> del pacchetto SimpleTest:
 <php><![CDATA[
 <?php
 require_once('simpletest/xml.php');
@@ -383,27 +380,27 @@
 $parser->parse($test_output);
 ?>
 ]]></php>
-                The <code>$test_output</code> should be the XML format
-                from the XML reporter, and could come from say a command
-                line run of a test case.
-                The parser sends events to the reporter just like any
-                other test run.
-                There are some odd occasions where this is actually useful.
+				<code>$test_output</code> dovrebbe essere il testo XML
+				prodotto dal reporter XML e potrebbe giungere dall'esecuzione
+				di un test case da riga di comando.
+				Il parser invia gli eventi al reporter esattamente come in
+				ogni altra esecuzione di test.
+                Ci sono alcuni casi particolari dove questo può risultare utile.
             </p>
             <p>
-                A problem with large test suites is thet they can exhaust
-                the default 8Mb memory limit on a PHP process.
-                By having the test groups output in XML and run in
-                separate processes, the output can be reparsed to
-                aggregate the results into a much smaller footprint top level
-                test.
+				Un problema con test suite particolarmente grandi è che possono
+				esaurire il limite standard di 8Mb a disposizione del processo PHP.
+				Con un output in XML e l'esecuzione in processi separati, l'output
+				può essere inviato successivamente al parser affinché produca un
+				risultato molto più leggero ad un test a livello più alto.
             </p>
             <p>
-                Because the XML output can come from anywhere, this opens
-                up the possibility of aggregating test runs from remote
-                servers.
-                A test case already exists to do this within the SimpleTest
-                framework, but it is currently experimental...
+				Dal momento che il risultato XML può essere stato prodotto ovunque,
+				questo apre la possibilità di aggregare i risultati delle esecuzioni di test di
+				server remoti.
+                Esiste un test case all'interno di SimpleTest che realizza questo risultato,

@@ Diff output truncated at 100000 characters. @@

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 1952
          http://simpletest.svn.sourceforge.net/simpletest/?rev=1952&view=rev
Author:   arialdomartini
Date:     2009-09-15 13:55:45 +0000 (Tue, 15 Sep 2009)

Log Message:
-----------
Web tester,
Form testing
Extectation

translated to Italian

Minor fixes in English version

Modified Paths:
--------------
    simpletest/trunk/docs/source/en/expectation_documentation.xml
    simpletest/trunk/docs/source/en/form_testing_documentation.xml
    simpletest/trunk/docs/source/it/expectation_documentation.xml
    simpletest/trunk/docs/source/it/form_testing_documentation.xml
    simpletest/trunk/docs/source/it/web_tester_documentation.xml

Modified: simpletest/trunk/docs/source/en/expectation_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/en/expectation_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
+++ simpletest/trunk/docs/source/en/expectation_documentation.xml	2009-09-15 13:55:45 UTC (rev 1952)
@@ -208,7 +208,7 @@
                 valid IP addresses.
                 In order to work correctly with the stubs and mocks the new
                 expectation class should extend
-                <code>SimpleExpectation</code> or forther extend a subclass...
+                <code>SimpleExpectation</code> or further extend a subclass...
 <php><![CDATA[
 <strong>class ValidIp extends SimpleExpectation {
     

Modified: simpletest/trunk/docs/source/en/form_testing_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/en/form_testing_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
+++ simpletest/trunk/docs/source/en/form_testing_documentation.xml	2009-09-15 13:55:45 UTC (rev 1952)
@@ -12,12 +12,12 @@
                 This results in any form controls that are inside &lt;form&gt; tags
                 being available from within the test case.
                 For example, if we have this snippet of HTML...
-<pre><![CDATA[
+<php><![CDATA[
 <form>
     <input type="text" name="a" value="A default" />
     <input type="submit" value="Go" />
 </form>
-]]></pre>
+]]></php>
                 Which looks like this...
             </p>
             <p>

Modified: simpletest/trunk/docs/source/it/expectation_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/expectation_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
+++ simpletest/trunk/docs/source/it/expectation_documentation.xml	2009-09-15 13:55:45 UTC (rev 1952)
@@ -2,32 +2,32 @@
 <!-- $Id: expectation_documentation.xml 1873 2009-06-12 16:12:18Z pp11 $ -->
 <page title="Le expectation" here="Le expectation">
     <long_title>
-        Extending the SimpleTest unit tester with additional expectation classes
+		Estendere lo unit tester di SimpleTest con nuove classi expectation.
     </long_title>
     <content>
         <section name="mock" title="Maggiore controllo sugli oggetti mock">
             <p>
-                The default behaviour of the
-                <a local="mock_objects_documentation">mock objects</a>
-                in
-                <a href="http://sourceforge.net/projects/simpletest/">SimpleTest</a>
-                is either an identical match on the argument or to allow any argument at all.
-                For almost all tests this is sufficient.
-                Sometimes, though, you want to weaken a test case.
+                Il comportamento standard degli <a local="mock_objects_documentation">oggetti mock</a>
+				di <a href="http://sourceforge.net/projects/simpletest/">SimpleTest</a> è di
+				prevedere un'esatta coincidenza degli argomenti o di accettarli tutti indistintamente.
+				Per la maggior parte dei test questo è sufficiente.
+				A volte, però, si potrebbe desiderare un case test più debole.
             </p>
             <p>
-                One place where a test can be too tightly coupled is with
-                text matching.
-                Suppose we have a component that outputs a helpful error
-                message when something goes wrong.
-                You want to test that the correct error was sent, but the actual
-                text may be rather long.
-                If you test for the text exactly, then every time the exact wording
-                of the message changes, you will have to go back and edit the test suite.
+				Un aspetto sul quale un test potrebbe rivelarsi troppo
+				fortemente accoppiato è nel match dei testi.
+				Si supponga, ad esempio, di disporre di un componente che
+				restituisca un messaggio di errore quando qualcosa sia andato
+				storto.
+				Si desidera eseguire il collaudo sulla correttezza dell'errore
+				riceuto ma il suo testo potrebbe essere piuttosto lungo.
+                Se si dovesse scrivere il test in funzione del testo esatto, ogni
+				volta che il messaggio viene modificato si deve tornare sui propri
+				passi e modificare di conseguenza anche la test suite.
             </p>
             <p>
-                For example, suppose we have a news service that has failed
-                to connect to its remote source.
+				Per fare un esempio, supponiamo di avere un servizio di new
+				che fallisca nel tentativo di collegarsi alla sorgente remota.
 <php><![CDATA[
 <strong>class NewsService {
     ...
@@ -41,10 +41,11 @@
     }
 }</strong>
 ]]></php>
-                Here it is sending its content to a
-                <code>Writer</code> class.
-                We could test this behaviour with a
-                <code>MockWriter</code> like so...
+				Il servizio invia il contenuto ad una classe
+                <code>Writer</code>.
+				Si potrebbe pensare di collaudare questo
+				comportamento con un 
+                <code>MockWriter</code>, in questo modo:
 <php><![CDATA[
 class TestOfNewsService extends UnitTestCase {
     ...
@@ -60,16 +61,16 @@
     }
 }
 ]]></php>
-                This is a good example of a brittle test.
-                If we decide to add additional instructions, such as
-                suggesting an alternative news source, we will break
-                our tests even though no underlying functionality
-                has been altered.
+				Questo è il tipico esempio di test debole.
+                Se solo si decidesse di aggiungere nuove istruzioni,
+				come il suggerimento di fonti di news alternative,
+				il test smetterebbe di funzionare nonostante nessuna  sottostante
+				funzionalità risulterebbe alterata.
             </p>
             <p>
-                To get around this, we would like to do a regular expression
-                test rather than an exact match.
-                We can actually do this with...
+				Per risolvere casi come questi, sarebbe comodo eseguire il match
+				con un'espressione regolare, piuttosto che con l'esatta stringa.
+                Si potrebbe cioè fare:
 <php><![CDATA[
 class TestOfNewsService extends UnitTestCase {
     ...
@@ -84,95 +85,96 @@
     }
 }
 ]]></php>
-                Instead of passing in the expected parameter to the
-                <code>MockWriter</code> we pass an
-                expectation class called
-                <code>PatternExpectation</code>.
-                The mock object is smart enough to recognise this as special
-                and to treat it differently.
-                Rather than simply comparing the incoming argument to this
-                object, it uses the expectation object itself to
-                perform the test.
+				Piuttosto che passare il <code>MockWriter</code> come parametro
+				si è passata una classe chiamata <code>PatternExpectation</code>.
+				L'oggetto mock è abbastanza intelligente per riconoscere che è
+				un caso speciale e lo tratta differentemente.
+                Invece di limitarsi a confrontare l'argomento in entrata con
+				l'oggetto, utilizza lo stesso oggetto expectation per eseguire il
+				test.
             </p>
             <p>
-                The <code>PatternExpectation</code> takes
-                the regular expression to match in its constructor.
-                Whenever a comparison is made by the <code>MockWriter</code>
-                against this expectation class, it will do a
-                <code>preg_match()</code> with this pattern.
-                With our test case above, as long as &quot;cannot connect&quot;
-                appears in the text of the string, the mock will issue a pass
-                to the unit tester.
-                The rest of the text does not matter.
+				<code>PatternExpectation</code> accetta l'espressione regolare da
+				utilizzare per il confronto come parametro del costruttore.
+				Ogni volta che <code>MockWriter</code> esegue una comparazione
+				con la classe expectation, utilizzerà <code>preg_match()</code> con
+				l'espressione regolare fornita.
+				Con il case test appena vista, ogni volta che la stringa
+				&quot;cannot connect&quot; compare nel testo del messaggio, il mock
+				segnalerà un evento di successo allo unit tester.
+				Il resto del testo verrà ignorato.
             </p>
             <p>
-                The possible expectation classes are...
+				Le possibili classi expectation sono:
                 <table><tbody>
-                    <tr><td><code>AnythingExpectation</code></td><td>Will always match</td></tr>
-                    <tr><td><code>EqualExpectation</code></td><td>An equality, rather than the stronger identity comparison</td></tr>
-                    <tr><td><code>NotEqualExpectation</code></td><td>An inequality comparison</td></tr>
-                    <tr><td><code>IndenticalExpectation</code></td><td>The default mock object check which must match exactly</td></tr>
-                    <tr><td><code>NotIndenticalExpectation</code></td><td>Inverts the mock object logic</td></tr>
-                    <tr><td><code>WithinMarginExpectation</code></td><td>Compares a value to within a margin</td></tr>
-                    <tr><td><code>OutsideMarginExpectation</code></td><td>Checks that a value is out side the margin</td></tr>
-                    <tr><td><code>PatternExpectation</code></td><td>Uses a Perl Regex to match a string</td></tr>
-                    <tr><td><code>NoPatternExpectation</code></td><td>Passes only if failing a Perl Regex</td></tr>
-                    <tr><td><code>IsAExpectation</code></td><td>Checks the type or class name only</td></tr>
-                    <tr><td><code>NotAExpectation</code></td><td>Opposite of the <code>IsAExpectation</code></td></tr>
-                    <tr><td><code>MethodExistsExpectation</code></td><td>Checks a method is available on an object</td></tr>
-                    <tr><td><code>TrueExpectation</code></td><td>Accepts any PHP variable that evaluates to true</td></tr>
-                    <tr><td><code>FalseExpectation</code></td><td>Accepts any PHP variable that evaluates to false</td></tr>
+                    <tr><td><code>AnythingExpectation</code></td><td>Corrisponde sempre</td></tr>
+                    <tr><td><code>EqualExpectation</code></td><td>Confronto di mera uguaglianza piuttosto che di indentità</td></tr>
+                    <tr><td><code>NotEqualExpectation</code></td><td>Comparazione di ineguaglianza</td></tr>
+                    <tr><td><code>IndenticalExpectation</code></td><td>E' la comparazione standard degli oggetti mock e confronta l'esatta uguaglianza</td></tr>
+                    <tr><td><code>NotIndenticalExpectation</code></td><td>Inverte la logica dell'oggetto mock</td></tr>
+                    <tr><td><code>WithinMarginExpectation</code></td><td>Confronta due valore entro un margine di tolleranza</td></tr>
+                    <tr><td><code>OutsideMarginExpectation</code></td><td>verifica che un valore sia al di fuori di un intervallo</td></tr>
+                    <tr><td><code>PatternExpectation</code></td><td>Utilizz il Regex di Perl per il match di una stringa</td></tr>
+                    <tr><td><code>NoPatternExpectation</code></td><td>Passa solo nel caso il Regex di Perl falisca</td></tr>
+                    <tr><td><code>IsAExpectation</code></td><td>Verifica solo il tipo della classe o il suo nome</td></tr>
+                    <tr><td><code>NotAExpectation</code></td><td>L'opposto di <code>IsAExpectation</code></td></tr>
+                    <tr><td><code>MethodExistsExpectation</code></td><td>Verifica che un certo metodo sia disponibile in un oggetto</td></tr>
+                    <tr><td><code>TrueExpectation</code></td><td>Accetta qualsiasi variabile che PHP valuti true</td></tr>
+                    <tr><td><code>FalseExpectation</code></td><td>Accetta qualsiasi variabile che PHP valuti false</td></tr>
                 </tbody></table>
-                Most take the expected value in the constructor.
-                The exceptions are the pattern matchers, which take a regular expression,
-                and the <code>IsAExpectation</code> and <code>NotAExpectation</code> which takes a type
-                or class name as a string.
+				La maggior parte delle expectation accettano il valore atteso nel costruttore.
+				Le expectation sono comparatori di pattern che accettano espressioni regolari e 
+				<code>IsAExpectation</code> e <code>NotAExpectation</code> che accettano un tipo o un nome
+				di classe come stringhe.
             </p>
             <p>
-                Some examples...
+                Vediamo alcuni esempi:
             </p>
             <p>
 <php><![CDATA[
 $mock->expectOnce('method', array(new IdenticalExpectation(14)));
 ]]></php>
-                This is the same as <code>$mock->expectOnce('method', array(14))</code>.
+				Questo è equivalente a <code>$mock->expectOnce('method', array(14))</code>.
 <php><![CDATA[
 $mock->expectOnce('method', array(new EqualExpectation(14)));
 ]]></php>
-                This is different from the previous version in that the string
-                <code>"14"</code> as a parameter will also pass.
-                Sometimes the additional type checks of SimpleTest are too restrictive.
+				Questo è diverso dall'esempio precedente, il quale avrebbe
+				accettat anche la stringa <code>"14"</code>.
+				A volte, il controllo aggiuntivo del tipo è troppo restrittivo.
 <php><![CDATA[
 $mock->expectOnce('method', array(new AnythingExpectation(14)));
 ]]></php>
-                This is the same as <code>$mock->expectOnce('method', array('*'))</code>.
+				Questo è equivalente a <code>$mock->expectOnce('method', array('*'))</code>.
 <php><![CDATA[
 $mock->expectOnce('method', array(new IdenticalExpectation('*')));
 ]]></php>
-                This is handy if you want to assert a literal <code>"*"</code>.
+				Questo può essere comodo ogni volta che si voglia specificare un
+				<code>"*"</code> letteralmente.
 <php><![CDATA[
 new NotIdenticalExpectation(14)
 ]]></php>
-                This matches on anything other than integer 14.
-                Even the string <code>"14"</code> would pass.
+				Questo match accetta qualsiasi parametro eccetto
+				l'intero 14.
+				Anche la stringa <code>"14"</code> viene accettata.
 <php><![CDATA[
 new WithinMarginExpectation(14.0, 0.001)
 ]]></php>
-                This will accept any value from 13.999 to 14.001 inclusive.
+				Accetta qualsiasi valore tra 13.999 e 14.001 inclusi.
             </p>
         </section>
-        <section name="behaviour" title="Usare le expectation per controllare gli stub">
+        <section name="behaviour" title="Cambiare il comportamento dei mock mediante le expectation">
             <p>
-                The expectation classes can be used not just for sending assertions
-                from mock objects, but also for selecting behaviour for the
-                <a local="mock_objects_documentation">mock objects</a>.
-                Anywhere a list of arguments is given, a list of expectation objects
-                can be inserted instead.
+				Le classi expectation possono essere utilizzate non soltanto per
+				inviare messaggi di assert ai mock ma anche per selezionare i
+				comportamenti che i <a local="mock_objects_documentation">mock</a>. devono assumere.
+                Ovunque sia previsto un elenco di argomenti è possibile fornire, al suo posto,
+				un elenco di oggetti expectation.
             </p>
             <p>
-                Suppose we want a mock authorisation server to simulate a successful login,
-                but only if it receives a valid session object.
-                We can do this as follows...
+				Supponiamo si voglia un mock di un server di autenticazione per simulare
+				un login che si concluda con successo solo nel caso venga ricevuto un
+				oggetto di sessione valido.
+				Si potrebbe agire così:
 <php><![CDATA[
 Mock::generate('Authorisation');
 <strong>
@@ -183,32 +185,30 @@
         array(new IsAExpectation('Session', 'Must be a session')));
 $authorisation->returns('isAllowed', false);</strong>
 ]]></php>
-                We have set the default mock behaviour to return false when
-                <code>isAllowed</code> is called.
-                When we call the method with a single parameter that
-                is a <code>Session</code> object, it will return true.
-                We have also added a second parameter as a message.
-                This will be displayed as part of the mock object
-                failure message if this expectation is the cause of
-                a failure.
+				Si è impostato il comportamento standard del mock per restituire
+				false nel caso venga invocato <code>isAllowed</code>.
+				Quando il metodo viene invocato con un oggetto <code>Session</code>
+				come unico parametro, verrà restituito true.
+				Si è anche previsto un secondo parametro come messaggio:
+				questo verrà visualizzato come parte del messaggio di fallimento
+				del mock nel caso la expectation sia la casua della failure.
             </p>
             <p>
-                This kind of sophistication is rarely useful, but is included for
-                completeness.
+				Questo meccasimo sofisticato è utilizzato piuttosto raramente ma è
+				stato incluso per completezza.
             </p>
         </section>
-        <section name="extending" title="Crearsi le proprie expectation">
+        <section name="extending" title="Estendere le expectation">
             <p>
-                The expectation classes have a very simple structure.
-                So simple that it is easy to create your own versions for
-                commonly used test logic.
+				Le classi expectation hanno una struttura molto semplice.
+				Talmente semplice che risulta molto facile crearne di proprie
+				per le più comuni esigenze di test.
             </p>
             <p>
-                As an example here is the creation of a class to test for
-                valid IP addresses.
-                In order to work correctly with the stubs and mocks the new
-                expectation class should extend
-                <code>SimpleExpectation</code> or forther extend a subclass...
+				L'esempio qui riportato riguarda il collaudo di indirizzi IP validi.
+				Allo scopo di far funzionare correttamente stub e mock, le nuove
+				classi expectation dovrebbero estendere <code>SimpleExpectation</code>
+				o, al più, una sua sottoclasse:
 <php><![CDATA[
 <strong>class ValidIp extends SimpleExpectation {
     
@@ -221,20 +221,18 @@
     }
 }</strong>
 ]]></php>
-                There are only two methods to implement.
-                The <code>test()</code> method should
-                evaluate to true if the expectation is to pass, and
-                false otherwise.
-                The <code>testMessage()</code> method
-                should simply return some helpful text explaining the test
-                that was carried out.
+				Ci sono solo due metodi da implementare.
+				Il metodo <code>test()</code> deve restituire true
+				nel caso di expectation passata e false altrimenti.
+				Il metodo <code>testMessage()</code> dovrebbe semplicemente
+				restituire un messaggio explicativo che sia di aiuto per
+				capire come il test è stato eseguito.
             </p>
             <p>
-                This class can now be used in place of the earlier expectation
-                classes.
+				A questo punto la classe può essere usata al posto della precedente.
             </p>
             <p>
-                Here is a more typical example, matching part of a hash...
+				Di seguito un esempio più comune, che segue il match di una parte di un hash:
 <php><![CDATA[
 <strong>class JustField extends EqualExpectation {
     private $key;
@@ -260,15 +258,17 @@
     }
 }</strong>
 ]]></php>
-                We tend to seperate message clauses with
-                &quot;<![CDATA[&nbsp;->&nbsp;]]>&quot;.
-                This allows derivative tools to reformat the output.
+				Una convenzione è quella di separare le parti
+				del masseaggio con
+                &quot;<![CDATA[&nbsp;->&nbsp;]]>&quot;,
+				in modo da facilitare eventuali altri tool nella
+				formattazione dell'output.
             </p>
             <p>
-                Suppose some authenticator is expecting to be given
-                a database row corresponding to the user, and we
-                only need to confirm the username is correct.
-                We can assert just their username with...
+				Supposiamo che un sistema di autenticazione si attenda
+				una riga proveniente dal database e corrispondente all'utente
+				e che si debba verificare che la username sia corretta.
+				Si potrà verificare la username con:
 <php><![CDATA[
 $mock->expectOnce('authenticate',
                   array(new JustKey('username', 'marcus')));
@@ -277,16 +277,16 @@
         </section>
         <section name="unit" title="Dentro il cofano dello unit tester">
             <p>
-                The <a href="http://sourceforge.net/projects/simpletest/">SimpleTest unit testing framework</a>
-                also uses the expectation classes internally for the
-                <a local="unit_test_documentation">UnitTestCase class</a>.
-                We can also take advantage of these mechanisms to reuse our
-                homebrew expectation classes within the test suites directly.
+				<a href="http://sourceforge.net/projects/simpletest/">SimpleTest unit testing framework</a>
+				utilizza internamente le classi expectation nella classe
+				<a local="unit_test_documentation">UnitTestCase</a>.
+                Possiamo avvantaggiarci di questi meccanismi per il riutilizzo
+				delle classi expectation fatte in casa direttamente all'interno
+				delle suite di test.
             </p>
             <p>
-                The most crude way of doing this is to use the generic
-                <code>SimpleTest::assert()</code> method to
-                test against it directly...
+				Il modo più rozzo per farlo è usare il metodo generico
+                <code>SimpleTest::assert()</code> per eseguire il test direttamente:
 <php><![CDATA[
 <strong>class TestOfNetworking extends UnitTestCase {
     ...
@@ -299,19 +299,20 @@
     }
 }</strong>
 ]]></php>
-                <code>assert()</code> will test any expectation class directly.
+                <code>assert()</code> eseguirà direttamente il test con la expecration fornita.
             </p>
             <p>
-                This is a little untidy compared with our usual
-                <code>assert...()</code> syntax.
+				In effetti, rispetto alla consueta sintassi di 
+				<code>assert...()</code> questo è un po' più disordinato.
+                
             </p>
             <p>
-                For such a simple case we would normally create a
-                separate assertion method on our test case rather
-                than bother using the expectation class.
-                If we pretend that our expectation is a little more
-                complicated for a moment, so that we want to reuse it,
-                we get...
+				In questo caso,  piuttosto che usare la classe
+				expectation direttamente, normalmente sarà preferibile creare un
+				metodo di assert separato.
+				Se per un attimo si immagina che la expectation sia 
+				più complicata abbastanza perché si desideri riutilizzarla,
+				si otterrà:
 <php><![CDATA[
 class TestOfNetworking extends UnitTestCase {
     ...<strong>
@@ -327,28 +328,29 @@
     }
 }
 ]]></php>
-                It is rare to need the expectations for more than pattern
-                matching, but these facilities do allow testers to build
-                some sort of domain language for testing their application.
-                Also, complex expectation classes could make the tests
-                harder to read and debug.
-                In effect extending the test framework to create their own tool set.
+				E' raro che una expectation debba eseguire il match di più pattern
+				ma questa facilitazione permette a chi si occupa di test di 
+				costruire una sorta di domain language per il collaudo delle proprie
+				applicazioni.
+				Inoltre, le classi expectation troppo complesse rendono i test
+				difficili da leggere e debuggare.
+				In effetti, estendere il framwork e creare il proprio set di strumenti
+				è il modo migliore di procedere.
             </p>
         </section>
     </content>
     <internal>
         <link>
-            Using expectations for
-            <a href="#mock">more precise testing with mock objects</a>
+            <a href="#mock">Estendere lo unit tester di SimpleTest con nuove classi expectation.</a>
         </link>
         <link>
-            <a href="#behaviour">Changing mock object behaviour</a> with expectations
+            <a href="#behaviour">Cambiare il comportamento dei mock mediante le expectation</a>
         </link>
         <link>
-            <a href="#extending">Extending the expectations</a>
+            <a href="#extending">Estendere le expectation</a>
         </link>
         <link>
-            Underneath SimpleTest <a href="#unit">uses expectation classes</a>
+            <a href="#unit">Dentro il cofano dello unit tester</a>
         </link>
     </internal>
     <external>

Modified: simpletest/trunk/docs/source/it/form_testing_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/form_testing_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
+++ simpletest/trunk/docs/source/it/form_testing_documentation.xml	2009-09-15 13:55:45 UTC (rev 1952)
@@ -3,22 +3,21 @@
 <page title="Il collaudo di form" here="Il collaudo di form">
     <long_title>SimpleTest documentation for testing HTML forms</long_title>
     <content>
-        <section name="submit" title="Fare il Submit di un semplice form">
+        <section name="submit" title="Modificare i valori dei form ed eseguire il submit di un semplice form">
             <p>
-                When a page is fetched by the <code>WebTestCase</code>
-                using <code>get()</code> or
-                <code>post()</code> the page content is
-                automatically parsed.
-                This results in any form controls that are inside &lt;form&gt; tags
-                being available from within the test case.
-                For example, if we have this snippet of HTML...
-<pre><![CDATA[
+				Quando una pagina viene recuperata da <code>WebTestCase</code>
+				tramite <code>get()</code> o <code>post()</code>
+				il contenuto della pagina viene automaticamente analizzato.
+                Il risultato è che ogni elemento contenuto dentro un tag
+				&lt;form&gt; risulterà disponibile all'interno del test case.
+				Per esempio, con questo snippet HTML:
+<php><![CDATA[
 <form>
     <input type="text" name="a" value="A default" />
     <input type="submit" value="Go" />
 </form>
-]]></pre>
-                Which looks like this...
+]]></php>
+				che avrebbe questo aspetto:
             </p>
             <p>
                 <form class="demo">
@@ -27,9 +26,9 @@
                 </form>
             </p>
             <p>
-                We can navigate to this code, via the
-                <a href="http://www.lastcraft.com/form_testing_documentation.php">LastCraft</a>
-                site, with the following test...
+				si potrebbe navigare il codice, sul sito 
+				<a href="http://www.lastcraft.com/form_testing_documentation.php">LastCraft</a>
+				con il seguente test:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {<strong>
     function testDefaultValue() {
@@ -38,13 +37,12 @@
     }</strong>
 }
 ]]></php>
-                Immediately after loading the page all of the HTML controls are set at
-                their default values just as they would appear in the web browser.
-                The assertion tests that a HTML widget exists in the page with the
-                name &quot;a&quot; and that it is currently set to the value
-                &quot;A default&quot;.
-                As usual, we could use a pattern expectation instead of a fixed
-                string.
+				Immediatamente dopo il caricamento della pagina, tutti gli elementi HTML
+				vengono impostati al loro valore di default, proprio come nel caso
+				apparissero nel browser.
+				Gli assert dell'esempio si assicurano che nella pagina esista un widget HTML con il nome &quot;a&quot;
+				e che il suo valore sia &quot;A default&quot;..
+                Al solito, è possibile utilizzare un pattern invece di una stringa statica:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     function testDefaultValue() {
@@ -53,8 +51,9 @@
     }
 }
 ]]></php>
-                We could submit the form straight away, but first we'll change
-                the value of the text field and only then submit it...
+				Si potrebbe eseguire il submit del form così com'è, ma prima
+				si proverà a modificare il valore del campo di testo e solo allora
+				si farà il submit:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     function testDefaultValue() {
@@ -65,24 +64,25 @@
     }
 }
 ]]></php>
-                Because we didn't specify a method attribute on the form tag, and
-                didn't specify an action either, the test case will follow
-                the usual browser behaviour of submitting the form data as a <em>GET</em>
-                request back to the same location.
-                In general SimpleTest tries to emulate typical browser behaviour as much as possible,
-                rather than attempting to catch any form of HTML omission.
-                This is because the target of the testing framework is the PHP application
-                logic, not syntax or other errors in the HTML code.
-                For HTML errors, other tools such as
-                <a href="http://www.w3.org/People/Raggett/tidy/">HTMLTidy</a> should be used,
-                or any of the HTML and CSS validators already out there.
+				Siccome non è stato specificato un attributo method nel tag form e
+				nemmeno una action, il test case seguirà l'usuale comportameto di un
+				browser ed effettuerà il submit dei dati del form con una richiesta 
+				<em>GET</em> allo stesso indirizzo.
+				In generale, piuttosto che cercare di individuare gli elementi mancanti in un form,
+				SimpleTest cerca di emulare il più possibile il tipico comportamento di un
+				browser.
+                Il motivo di questo è che l'obiettivo di un framework di test è il collaudo
+				della logica di un'applicazione PHP e non la valutazione della correttezza
+				sintattica del codice HTML.
+				Per gli errori HTML dovrebbero essere utilizzati altri tool come 
+				<a href="http://www.w3.org/People/Raggett/tidy/">HTMLTidy</a> o qualsiasi
+				altro validatore HTML e CSS già sul mercato.
             </p>
             <p>
-                If a field is not present in any form, or if an option is unavailable,
-                then <code>WebTestCase::setField()</code> will return
-                <code>false</code>.
-                For example, suppose we wish to verify that a &quot;Superuser&quot;
-                option is not present in this form...
+				Se un campo non viene trovato in alcun form o se un'opzione non è disponibile,
+				allora <code>WebTestCase::setField()</code> restituirà <code>false</code>.
+				Per esempio, supponiamo che si voglia verificare che l'opzione &quot;Superuser&quot;
+				non sia presente su questo form:
 <pre><![CDATA[
 <strong>Select type of user to add:</strong>
 <select name="type">
@@ -91,7 +91,7 @@
     <option>Administrator</option>
 </select>
 ]]></pre>
-                Which looks like...
+                che apparirebbe così:
             </p>
             <p>
                 <form class="demo">
@@ -104,7 +104,7 @@
                 </form>
             </p>
             <p>
-                The following test will confirm it...
+                Il test seguente lo confermerebbe:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     ...
@@ -114,42 +114,41 @@
     }
 }
 ]]></php>
-                The current selection will not be changed if the new value is not an option.
+				Se il nuovo valore non è una delle opzioni, la selezione corrente non viene modificata.
             </p>
             <p>
-                Here is the full list of widgets currently supported...
+				Di seguito un elenco di tutti i widget correntemente supportati:
                 <ul>
-                    <li>Text fields, including hidden and password fields.</li>
-                    <li>Submit buttons including the button tag, although not yet reset buttons</li>
-                    <li>Text area. This includes text wrapping behaviour.</li>
-                    <li>Checkboxes, including multiple checkboxes in the same form.</li>
-                    <li>Drop down selections, including multiple selects.</li>
-                    <li>Radio buttons.</li>
-                    <li>Images.</li>
+                    <li>Campi di testo, compresi i campi nascosti e le password.</li>
+                    <li>Pulsanti di submit, compreso il tag button ma escluso il pulsante reset</li>
+                    <li>Text area. E' compreso anche il comportamento "A capo automatico"</li>
+                    <li>Checkboxe,  compresi i checkboxe multipli all'interno dello stesso form</li>
+                    <li>Elenchi a cascata, inclusi quelli con selezione multipla</li>
+                    <li>Radio buttons</li>
+                    <li>Immagini</li>
                 </ul>
             </p>
             <p>
-                The browser emulation offered by SimpleTest mimics
-                the actions which can be perform by a user on a
-                standard HTML page. Javascript is not supported, and
-                it's unlikely that support will be added any time
-                soon.
+				L'emulazione del browser offerta da Simpletest imita
+				le azioni che un utente può effettuare su una pagina
+				HTML standard. Javascript non è supportato ed è
+				improbabile che venga aggiunto il supporto a breve.
             </p>
             <p>
-                Of particular note is that the Javascript idiom of
-                passing form results by setting a hidden field cannot
-                be performed using the normal SimpleTest
-                commands. See below for a way to test such forms.
+				Un aspetto da tenere in considerazione è che la tecnica
+				Javascript di inviare i form dopo l'impostazione di un
+				campo nascosto non può essere emulata con i normali comandi
+				di SimplTest.
+				Si veda oltre per un sistema di collaudo di form di questo tipo.
             </p>
         </section>
-        <section name="multiple" title="Campi con valori multipli">
+        <section name="multiple" title="Gestire widget con valori multipli">
             <p>
-                SimpleTest can cope with two types of multivalue controls: Multiple
-                selection drop downs, and multiple checkboxes with the same name
-                within a form.
-                The multivalue nature of these means that setting and testing
-                are slightly different.
-                Using checkboxes as an example...
+				SimpleTest può gestire due tipi di controlli multivalore: i drop-down
+				multipli e i checkbox multipli all'interno dello stesso form.
+				La natura di questi elementi comporta che la loro impostazione
+				ed il loro collaudo debba essere eseguito in modo leggermente differente.
+				Vediamo un esempio con i checkbox:
 <pre><![CDATA[
 <form class="demo">
     <strong>Create privileges allowed:</strong>
@@ -163,7 +162,7 @@
     <input type="submit" value="Enable Privileges">
 </form>
 ]]></pre>
-                Which renders as...
+                Questo viene visualizzato come:
             </p>
             <p>
                 <form class="demo">
@@ -179,8 +178,9 @@
                 </form>
             </p>
             <p>
-                If we wish to disable all but the retrieval privileges and
-                submit this information we can do it like this...
+				Se si desidera disabilitare tutti i checkbox escluso
+				"Retrieve privileges allowed" ed eseguire poi il submit, si può
+				fare così:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     ...<strong>
@@ -192,18 +192,19 @@
     }</strong>
 }
 ]]></php>
-                Instead of setting the field to a single value, we give it a list
-                of values.
-                We do the same when testing expected values.
-                We can then write other test code to confirm the effect of this, perhaps
-                by logging in as that user and attempting an update.
+				Piuttosto che impostare il campo con un singolo valore, si è fornito
+				un elenco di valori.
+				Si fa la stessa cosa quando si verificano i valori attesi.
+				Si può procedere quindi scrivendo altri test per confermare l'effetto
+				di quest'ultimo, per esempio eseguendo il login con l'utente selezionato e tentando
+				di fare un update.
             </p>
         </section>
         <section name="hidden-field" title="Form che utilizzano Javascript per popolare campi nascosti">
             <p>
-                If you want to test a form which relies on javascript to set a hidden
-                field, you can't just call setField().
-                The following code will <em>not</em> work:
+				Se si vuole collaudare un form che fa affidamento sul fatto che Javascript
+				imposti un campo nascosto, non sarà sufficiente invocare setField().
+				Il codice riportato qui di seguito <em>non</em> funzionerà:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     function testEmulateMyJavascriptForm() {
@@ -213,8 +214,8 @@
     }
 }
 ]]></php>
-                Instead, you need to pass the additional form parameters to the
-                clickSubmit() method:
+				Piuttosto, ci sarà bisogno di passare dei parametri aggiuntivi
+				al metodo clickSubmit():
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     function testMyJavascriptForm() {
@@ -223,18 +224,17 @@
 
 }
 ]]></php>
-                Bear in mind that in doing this you're effectively stubbing out a
-                part of your software (the javascript code in the form), and
-                perhaps you might be better off using something like 
-                <a href="http://selenium.openqa.org/">Selenium</a> to ensure a complete
-                test.
+				Si tenga in mente che in questo modo si sta effettivamente cortocircuitando
+				una parte del proprio software (il codice javascript nel form) e forse sarebbe
+				meglio utilizzare strumenti come <a href="http://selenium.openqa.org/">Selenium</a>
+				per assicurare un collaudo più completo.
             </p>
         </section>
-        <section name="raw" title="Raw posting">
+        <section name="raw" title="Post manuale in assenza del pulsante di submit">
             <p>
-                If you want to test a form handler, but have not yet written
-                or do not have access to the form itself, you can create a
-                form submission by hand.
+				Se si vuole collaudare un gestore di form non non si è ancora
+				scritto il form o non vi si può accedere, è possibile invocare il
+				submit manualmente:
 <php><![CDATA[
 class SimpleFormTests extends WebTestCase {
     ...<strong>    
@@ -246,29 +246,29 @@
     }</strong>
 }
 ]]></php>
-                By adding data to the <code>WebTestCase::post()</code>
-                method, we are emulating a form submission.
-                You would normally only do this as a temporary expedient, or where
-                you are expecting a 3rd party to submit to a form.
-                The exception is when you want tests to protect you from
-                attempts to spoof your pages.
+				Aggiungendo <code>WebTestCase::post()</code>
+				si sta emulando il submit del form.
+				Normalmente si userà questo sistema come espediente provvisorio
+				o nel caso ci si aspetti che sia un componente di terze parti ad
+				eseguire il submit.
+				Un'eccezione a questo è quando si desidera collaudare la protezione
+				dai tentativi di spoofing delle pagine.
             </p>
         </section>
     </content>
     <internal>
         <link>
-            Changing form values and successfully
-            <a href="#submit">Submitting a simple form</a>
+            <a href="#submit">Modificare i valori dei form</a> ed eseguire il submit di un semplice form
         </link>
         <link>
-            Handling <a href="#multiple">widgets with multiple values</a>
-            by setting lists.
+            <a href="#multiple">Gestire widget con valori multipli</a>
+            
         </link>
         <link>
-            Bypassing javascript to <a href="#hidden-field">set a hidden field</a>.
+            <a href="#hidden-field">Form che utilizzano Javascript per popolare campi nascosti</a>.
         </link>
         <link>
-            <a href="#raw">Raw posting</a> when you don&apos;t have a button
+            <a href="#raw">Post manuale in assenza del pulsante di submit</a>
             to click.
         </link>
     </internal>

Modified: simpletest/trunk/docs/source/it/web_tester_documentation.xml
===================================================================
--- simpletest/trunk/docs/source/it/web_tester_documentation.xml	2009-09-14 16:14:29 UTC (rev 1951)
+++ simpletest/trunk/docs/source/it/web_tester_documentation.xml	2009-09-15 13:55:45 UTC (rev 1952)
@@ -5,42 +5,45 @@
     <content>
         <section name="fetch" title="Recuperare una pagina">
             <p>
-                Testing classes is all very well, but PHP is predominately
-                a language for creating functionality within web pages.
-                How do we test the front end presentation role of our PHP
-                applications?
-                Well the web pages are just text, so we should be able to
-                examine them just like any other test data.
+				Il collaudo delle classi è bello ed utile ma PHP è
+				principalmente un linguaggio per sviluppare funzionalità
+				dentro pagine web.
+				Com'è possibile collaudare il layer di presentazione di un'applicazione
+				PHP?
+				In fin dei conti, le pagine web non sono altro che stringhe di testo
+				e perciò si dovrebbe essere in grado di collaudarle esattamente
+				come ogni altro dato di test.
             </p>
             <p>
-                This leads to a tricky issue.
-                If we test at too low a level, testing for matching tags
-                in the page with pattern matching for example, our tests will
-                be brittle.
-                The slightest change in layout could break a large number of
-                tests.
-                If we test at too high a level, say using mock versions of a
-                template engine, then we lose the ability to automate some classes
-                of test.
-                For example, the interaction of forms and navigation will
-                have to be tested manually.
-                These types of test are extremely repetitive and error prone.
+				Questo introduce un problema delicato.
+				Se il collaudo avvenisse ad un livello troppo basso, il dover
+				verificare ogni singolo tag della pagina con dei pattern, ad esempio,
+				condurrebbe a dei test troppo fragili.
+				La più insignificante modifica nel layout potrebbe compromettere
+				il funzionamento di un gran numero di test.
+				Del resto, se si collaudasse ad un livello troppo alto, ad esempio
+				utilizzando una versione mock del template engine, si perderebbe
+				la possibilità di collaudare alcune classi del test.
+				Per esempio, l'interazione tra i form e la navigazione dovrebbe essere
+				collaudata manualmente.
+				Queste tipologie di test sono estremamente ripetitive e soggette ad errori.
             </p>
             <p>
-                SimpleTest includes a special form of test case for the testing
-                of web page actions.
-                The <code>WebTestCase</code> includes facilities
-                for navigation, content and cookie checks and form handling.
-                Usage of these test cases is similar to the
-                <a local="unit_tester_documentation">UnitTestCase</a>...
+				SimpleTest include una speciale forma di test case per il collaudo
+				delle azioni sulle pagine web.
+				<code>WebTestCase</code> comprende facilitazioni per la navigazione,
+				per la verifica del contenuto delle pagine e dei cookie e per la
+				manipolazione di form.
+				L'uso dei test case web è simile a quello di 
+                <a local="unit_tester_documentation">UnitTestCase</a>:
 <php><![CDATA[
 <strong>class TestOfLastcraft extends WebTestCase {
 }</strong>
 ]]></php>
-                Here we are about to test the
-                <a href="http://www.lastcraft.com/">Last Craft</a> site itself.
-                If this test case is in a file called <em>lastcraft_test.php</em>
-                then it can be loaded in a runner script just like unit tests...
+				Qui si sta per eseguire il test del sito 
+                <a href="http://www.lastcraft.com/">Last Craft</a> stesso.
+				Il test è ospitato in un file chiamato <em>lastcraft_test.php</em>
+				che può essere caricato da uno script proprio come gli unit test:
 <php><![CDATA[
 <?php
 require_once('simpletest/autorun.php');<strong>
@@ -55,13 +58,13 @@
 }
 ?>
 ]]></php>
-                I am using the text reporter here to more clearly
-                distinguish the web content from the test output.
+				Si sta usando il text reporter per distinguere più chiaramente il 
+				contenuto della pagina web dall'output testuale.
             </p>
             <p>
-                Nothing is being tested yet.
-                We can fetch the home page by using the
-                <code>get()</code> method...
+				Non è ancora stato definito alcun test.
+				E' possibile recuperare la home page con il metodo
+                <code>get()</code>:
 <php><![CDATA[
 class TestOfLastcraft extends WebTestCase {
     <strong>
@@ -70,31 +73,31 @@
     }</strong>
 }
 ]]></php>
-                The <code>get()</code> method will
-                return true only if page content was successfully
-                loaded.
-                It is a simple, but crude way to check that a web page
-                was actually delivered by the web server.
-                However that content may be a 404 response and yet
-                our <code>get()</code> method will still return true.
+				Il metodo <code>get()</code> restituisce true solo se il
+				contenuto della pagina è stato correttamente caricato.
+				E' un modo semplice ma rozzo per verificare che una pagina
+				web sia effettivamente restituita dal web server.
+				Anche nel caso il contenuto della pagina dovesse essere un
+				messaggio di errore 404 il metodo <code>get()</code>
+				continuerebbe a restituire true.
             </p>
             <p>
-                Assuming that the web server for the Last Craft site is up
-                (sadly not always the case), we should see...
+				Supponiamo che  il web server di Last Craft sia attivo
+				(sfortunatamente non è sempre così), si vedrebbe:
 <pre class="shell">
 Web site tests
 OK
 Test cases run: 1/1, Failures: 0, Exceptions: 0
 </pre>
-                All we have really checked is that any kind of page was
-                returned.
-                We don&apos;t yet know if it was the right one.
+                Tutto quello che si è verificato, in sostanza, è che il web
+				server restituisca una qualsiasi pagina ma ancora non sappiamo
+				se sia quella corretta.
             </p>
         </section>
         <section name="content" title="Collaudare il contenuto della pagina">
             <p>
-                To confirm that the page we think we are on is actually the
-                page we are on, we need to verify the page content.
+				Per garantire che la pagina sulla quale ci si trovi sia quella
+				prevista, abbiamo bisogno di verificarne il contenuto.
 <php><![CDATA[
 class TestOfLastcraft extends WebTestCase {
     
@@ -104,57 +107,60 @@
     }
 }
 ]]></php>
-                The page from the last fetch is held in a buffer in
-                the test case, so there is no need to refer to it directly.
-                The pattern match is always made against the buffer.
+				La pagina prelevata precedentemente viene conservata in un
+				buffer del test case perciò non c'è la necessità di referenziarla
+				direttamente.
+				Il pattern match viene sempre eseguito sul contenuto del buffer.
             </p>
             <p>
+				Di seguito è riportato un elenco dei possibili assert:
                 Here is the list of possible content assertions...
                 <table><tbody>
-                    <tr><td><code>assertTitle($title)</code></td><td>Pass if title is an exact match</td></tr>
-                    <tr><td><code>assertText($text)</code></td><td>Pass if matches visible and &quot;alt&quot; text</td></tr>
-                    <tr><td><code>assertNoText($text)</code></td><td>Pass if doesn&apos;t match visible and &quot;alt&quot; text</td></tr>
-                    <tr><td><code>assertPattern($pattern)</code></td><td>A Perl pattern match against the page content</td></tr>
-                    <tr><td><code>assertNoPattern($pattern)</code></td><td>A Perl pattern match to not find content</td></tr>
-                    <tr><td><code>assertLink($label)</code></td><td>Pass if a link with this text is present</td></tr>
-                    <tr><td><code>assertNoLink($label)</code></td><td>Pass if no link with this text is present</td></tr>
-                    <tr><td><code>assertLinkById($id)</code></td><td>Pass if a link with this id attribute is present</td></tr>
-                    <tr><td><code>assertNoLinkById($id)</code></td><td>Pass if no link with this id attribute is present</td></tr>
-                    <tr><td><code>assertField($name, $value)</code></td><td>Pass if an input tag with this name has this value</td></tr>
-                    <tr><td><code>assertFieldById($id, $value)</code></td><td>Pass if an input tag with this id has this value</td></tr>
-                    <tr><td><code>assertResponse($codes)</code></td><td>Pass if HTTP response matches this list</td></tr>
-                    <tr><td><code>assertMime($types)</code></td><td>Pass if MIME type is in this list</td></tr>
-                    <tr><td><code>assertAuthentication($protocol)</code></td><td>Pass if the current challenge is this protocol</td></tr>
-                    <tr><td><code>assertNoAuthentication()</code></td><td>Pass if there is no current challenge</td></tr>
+                    <tr><td><code>assertTitle($title)</code></td><td>Passa se il titolo corrisponde esattamente</td></tr>
+                    <tr><td><code>assertText($text)</code></td><td>Passa se un testo visibile o un &quot;alt&quot; corrisponde al pattern</td></tr>
+                    <tr><td><code>assertNoText($text)</code></td><td>Passa se un testo visibile o un &quot;alt&quot; non corrisponde al pattern</td></tr>
+                    <tr><td><code>assertPattern($pattern)</code></td><td>Esegue un confronto tra il contenuto della pagina ed un pattern Perl</td></tr>
+                    <tr><td><code>assertNoPattern($pattern)</code></td><td>Passa se un pattern Perl fallisce sul contenuto della pagina</td></tr>
+                    <tr><td><code>assertLink($label)</code></td><td>Passa se viene trovato un link contenente il testo specificato</td></tr>
+                    <tr><td><code>assertNoLink($label)</code></td><td>Passa se non viene trovato un link contenente il testo specificato</td></tr>
+                    <tr><td><code>assertLinkById($id)</code></td><td>Passa se viene trovato un link con l'attributo id specificato</td></tr>
+                    <tr><td><code>assertNoLinkById($id)</code></td><td>Passa se non viene trovato alcun link con l'attributo id specificato</td></tr>
+                    <tr><td><code>assertField($name, $value)</code></td><td>Passa se viene trovato un tag input con l'attributo name specificato</td></tr>
+                    <tr><td><code>assertFieldById($id, $value)</code></td><td>Passa se viene trovato un tag input con l'attributo id specificato</td></tr>
+                    <tr><td><code>assertResponse($codes)</code></td><td>Passa se la risposta HTTP corrisponde all'elenco specificato</td></tr>
+                    <tr><td><code>assertMime($types)</code></td><td>Passa se viene trovato un MIME type dell'elenco</td></tr>
+                    <tr><td><code>assertAuthentication($protocol)</code></td><td>Passa se è stato utilizzato il protocollo di autenticazione specificato</td></tr>
+                    <tr><td><code>assertNoAuthentication()</code></td><td>Passa se non è stato utilizzato il protocollo di autenticazione specificato</td></tr>
                     <tr><td><code>assertRealm($name)</code></td><td>Pass if the current challenge realm matches</td></tr>
-                    <tr><td><code>assertHeader($header, $content)</code></td><td>Pass if a header was fetched matching this value</td></tr>
-                    <tr><td><code>assertNoHeader($header)</code></td><td>Pass if a header was not fetched</td></tr>
-                    <tr><td><code>assertCookie($name, $value)</code></td><td>Pass if there is currently a matching cookie</td></tr>
-                    <tr><td><code>assertNoCookie($name)</code></td><td>Pass if there is currently no cookie of this name</td></tr>
+                    <tr><td><code>assertHeader($header, $content)</code></td><td>Passa se c'è la corrispondenza con un campo dell'header</td></tr>
+                    <tr><td><code>assertNoHeader($header)</code></td><td>Passa se non c'è la corrispondenza con un campo dell'header</td></tr>
+                    <tr><td><code>assertCookie($name, $value)</code></td><td>Passa se viene trovato il cookie specificato</td></tr>
+                    <tr><td><code>assertNoCookie($name)</code></td><td>Passa se non viene trovato un cookie con il nome specificato</td></tr>
                 </tbody></table>
-                As usual with the SimpleTest assertions, they all return
-                false on failure and true on pass.
-                They also allow an optional test message and you can embed
-                the original test message inside using &quot;%s&quot; inside
-                your custom message.
+				Come le altre assert di SimpleTest, queste restituiscono false in caso
+				di fallimento e true in caso di successo.
+				E' anche permesso un parametro opzionale con un messaggio nel
+				quale è possibile includere il messaggio di test originale
+				per mezzo della stringa &quot;%s&quot;.
             </p>
             <p>
-                So now we could instead test against the title tag with...
+				Così, è possibile eseguire verifiche sul tag title con:
 <php><![CDATA[
 <strong>$this->assertTitle('The Last Craft? Web developer tutorials on PHP, Extreme programming and Object Oriented development');</strong>
 ]]></php>
-                ...or, if that is too long and fragile...
+                o, se queto fosse troppo fragile, con:
 <php><![CDATA[
 <strong>$this->assertTitle(new PatternExpectation('/The Last Craft/'));</strong>
 ]]></php>
-                As well as the simple HTML content checks we can check
-                that the MIME type is in a list of allowed types with...
+                Così come si può verificare il semplice contenuto HTML,
+				si può verificare che il MIME type sia compreso in un elenco
+				di MIME type consentiti, con:
 <php><![CDATA[
 <strong>$this->assertMime(array('text/plain', 'text/html'));</strong>
 ]]></php>
-                More interesting is checking the HTTP response code.
-                Like the MIME type, we can assert that the response code
-                is in a list of allowed values...
+				Più interessante è il collaudo del codice di risposta HTTP.
+				Come per il MIME type, si può verificare che il codice di risposta
+				sia incluso in un elenco di valori consentiti:
 <php><![CDATA[
 class TestOfLastcraft extends WebTestCase {
     
@@ -164,17 +170,19 @@
     }
 }
 ]]></php>
-                Here we are checking that the fetch is successful by
-                allowing only a 200 HTTP response.
-                This test will pass, but it is not actually correct to do so.
-                There is no page, instead the server issues a redirect.
-                The <code>WebTestCase</code> will
-                automatically follow up to three such redirects.
-                The tests are more robust this way and we are usually
-                interested in the interaction with the pages rather
-                than their delivery.
-                If the redirects are of interest then this ability must
-                be disabled...
+                Qui si sta verificando che il prelievo della pagina si sia
+				concluso con successo consentendo solo risposte con
+				codice HTTP 200.
+				Anche se questo testo passa non è esattamente pensato in modo corretto.
+				Se la pagina richiesta non esistesse ed il server eseguisse un redirect,
+				
+                <code>WebTestCase</code> seguirebbe automaticamente il redirect.
+				I test così pensati sono più robusti dal momento che, di solito,
+				si è interessati all'interazione con le pagine piuttosto che al
+				modo in cui queste vengono consegnate.
+                
+				Se l'esecuzione di un redirect è di nostro interesse, allora possiamo
+				sempre disabilitare questa caratteristica:
 <php><![CDATA[
 class TestOfLastcraft extends WebTestCase {
     
@@ -185,7 +193,7 @@
     }
 }
 ]]></php>
-                The assertion now fails as expected...
+				Adesso questa assert fallisce come richiesto:
 <pre class="shell">
 Web site tests
 1) Expecting response in [200] got [302]
@@ -195,7 +203,7 @@
 FAILURES!!!
 Test cases run: 1/1, Failures: 1, Exceptions: 0
 </pre>
-                We can modify the test to correctly assert redirects with...
+				Possiamo modificare il test per accettare anche i redirect così:
 <php><![CDATA[
 class TestOfLastcraft extends WebTestCase {
     
@@ -206,15 +214,15 @@
     }
 }
 ]]></php>
-                This now passes.
+                Adesso il test passa.
             </p>
         </section>
-        <section name="navigation" title="Navigare un sito web">
+        <section name="navigation" title="Navigare un sito durante il test">
             <p>
-                Users don&apos;t often navigate sites by typing in URLs, but by
-                clicking links and buttons.
-                Here we confirm that the contact details can be reached
-                from the home page...
+				Normalmente gli utenti non navigano il sito scrivendo gli URL,
+				ma cliccando su link e pulsanti.
+				Qui si verifica che la pagina con i contatti possa essere raggiunta
+				dalla home page:
 <php><![CDATA[
 class TestOfLastcraft extends WebTestCase {
     ...
@@ -225,126 +233,126 @@
     }
 }
 ]]></php>
-                The parameter is the text of the link.
+				Il parametro è il testo del link.
             </p>
             <p>
-                If the target is a button rather than an anchor tag, then
-                <code>clickSubmit()</code> can be used
-                with the button title...
+				Se l'oggetto da collaudare fosse un bottone piuttosto che un
+				anchor tag, allora è possibile usare
+                <code>clickSubmit()</code> sul pulsante specificato:
 <php><![CDATA[
 <strong>$this->clickSubmit('Go!');</strong>
 ]]></php>
-                If you are not sure or don&apos;t care, the usual case, then just
-                use the <code>click()</code> method...
+				Se non si è sicuri o non si vuole specificare il caso, come accade
+				di solito, è sufficiente usare il metodo <code>click()</code>:
 <php><![CDATA[
 <strong>$this->click('Go!');</strong>
 ]]></php>
             </p>
             <p>
-                The list of navigation methods is...
+                L'elenco dei metodi di navigazione è:
                 <table><tbody>
-                    <tr><td><code>getUrl()</code></td><td>The current location</td></tr>
-                    <tr><td><code>get($url, $parameters)</code></td><td>Send a GET request with these parameters</td></tr>
-                    <tr><td><code>post($url, $parameters)</code></td><td>Send a POST request with these parameters</td></tr>
-                    <tr><td><code>head($url, $parameters)</code></td><td>Send a HEAD request without replacing the page content</td></tr>
-                    <tr><td><code>retry()</code></td><td>Reload the last request</td></tr>
-                    <tr><td><code>back()</code></td><td>Like the browser back button</td></tr>
-                    <tr><td><code>forward()</code></td><td>Like the browser forward button</td></tr>
-                    <tr><td><code>authenticate($name, $password)</code></td><td>Retry after a challenge</td></tr>
-                    <tr><td><code>restart()</code></td><td>Restarts the browser as if a new session</td></tr>
-                    <tr><td><code>getCookie($name)</code></td><td>Gets the cookie value for the current context</td></tr>
-                    <tr><td><code>ageCookies($interval)</code></td><td>Ages current cookies prior to a restart</td></tr>
+                    <tr><td><code>getUrl()</code></td><td>Restituisce la posizione corrente</td></tr>
+                    <tr><td><code>get($url, $parameters)</code></td><td>Invia una richiesta GET con i parametri specificati</td></tr>
+                    <tr><td><code>post($url, $parameters)</code></td><td>Invia una richiesta POST con i parametri specificati</td></tr>
+                    <tr><td><code>head($url, $parameters)</code></td><td>Invia una richiesta HEAD senza sostituire il contenuto della pagina</td></tr>
+                    <tr><td><code>retry()</code></td><td>Ripete l'ultima richiesta</td></tr>
+                    <tr><td><code>back()</code></td><td>Si comporta come il pulsante Indietro del browser</td></tr>
+                    <tr><td><code>forward()</code></td><td>Si comporta come il pulsante Avanti del browser</td></tr>
+                    <tr><td><code>authenticate($name, $password)</code></td><td>Riprova un tentativo di autenticazione</td></tr>
+                    <tr><td><code>restart()</code></td><td>Riavvia il browser con una nuova sessione</td></tr>
+                    <tr><td><code>getCookie($name)</code></td><td>Recupera il valore di un cookie dal contesto corrente</td></tr>
+                    <tr><td><code>ageCookies($interval)</code></td><td>fa invecchiare i cookie della sessione prima di un riavvio</td></tr>
                     <tr><td><code>clearFrameFocus()</code></td><td>Go back to treating all frames as one page</td></tr>
-                    <tr><td><code>clickSubmit($label)</code></td><td>Click the first button with this label</td></tr>
-                    <tr><td><code>clickSubmitByName($name)</code></td><td>Click the button with this name attribute</td></tr>
-                    <tr><td><code>clickSubmitById($id)</code></td><td>Click the button with this ID attribute</td></tr>
-                    <tr><td><code>clickImage($label, $x, $y)</code></td><td>Click an input tag of type image by title or alt text</td></tr>
-                    <tr><td><code>clickImageByName($name, $x, $y)</code></td><td>Click an input tag of type image by name</td></tr>
-                    <tr><td><code>clickImageById($id, $x, $y)</code></td><td>Click an input tag of type image by ID attribute</td></tr>
-                    <tr><td><code>submitFormById($id)</code></td><td>Submit a form without the submit value</td></tr>
-                    <tr><td><code>clickLink($label, $index)</code></td><td>Click an anchor by the visible label text</td></tr>
-                    <tr><td><code>clickLinkById($id)</code></td><td>Click an anchor by the ID attribute</td></tr>
-                    <tr><td><code>getFrameFocus()</code></td><td>The name of the currently selected frame</td></tr>
-                    <tr><td><code>setFrameFocusByIndex($choice)</code></td><td>Focus on a frame counting from 1</td></tr>
-                    <tr><td><code>setFrameFocus($name)</code></td><td>Focus on a frame by name</td></tr>
+                    <tr><td><code>clickSubmit($label)</code></td><td>Preme il primo button che abbia la label specificata</td></tr>
+                    <tr><td><code>clickSubmitByName($name)</code></td><td>Preme il pulsante con il nome specificato</td></tr>
+                    <tr><td><code>clickSubmitById($id)</code></td><td>Preme il pulsante con l'id specificato</td></tr>
+                    <tr><td><code>clickImage($label, $x, $y)</code></td><td>Preme sul tag input di tipo image con il titolo o il tag alt specificato</td></tr>
+                    <tr><td><code>clickImageByName($name, $x, $y)</code></td><td>Preme sul tag input di tipo image con il nome specificato</td></tr>
+                    <tr><td><code>clickImageById($id, $x, $y)</code></td><td>Preme sul tag input di tipo image con l'id specificato</td></tr>
+                    <tr><td><code>submitFormById($id)</code></td><td>Esegue il submit di un form senza inviare il valore di submit</td></tr>
+                    <tr><td><code>clickLink($label, $index)</code></td><td>Preme l'anchor che abbia la label specificata</td></tr>
+                    <tr><td><code>clickLinkById($id)</code></td><td>Preme l'anchor che abbia l'id specificato</td></tr>
+                    <tr><td><code>getFrameFocus()</code></td><td>Restituisce il ome del frame correntemente selezionato</td></tr>
+                    <tr><td><code>setFrameFocusByIndex($choice)</code></td><td>Seleziona il frame specificato, contando i frame a partire da 1</td></tr>
+                    <tr><td><code>setFrameFocus($name)</code></td><td>Seleziona il frame con il nome specificato</td></tr>
                 </tbody></table>
             </p>
             <p>
-                The parameters in the <code>get()</code>, <code>post()</code> or
-                <code>head()</code> methods are optional.
-                The HTTP HEAD fetch does not change the browser context, only loads
-                cookies.
-                This can be useful for when an image or stylesheet sets a cookie
-                for crafty robot blocking.
+				I parametri dei metodi <code>get()</code>, <code>post()</code>
+				e <code>head()</code> sono opzionali.
+                Il recupero dell'HEAD HTTP non modifica il contesto del browser ma si limita
+				a caricare i cookie.
+				Questo può risultare utile quando un'immagine o uno stylesheet
+				imposta un cookie per bloccare i robot più astuti.
             </p>
             <p>
-                The <code>retry()</code>, <code>back()</code> and
-                <code>forward()</code> commands work as they would on
-                your web browser.
-                They use the history to retry pages.
-                This can be handy for checking the effect of hitting the
-                back button on your forms.
+				I comandi <code>retry()</code>, <code>back()</code> e
+                <code>forward()</code> funzionano esattamente come i
+				corrispondenti comandi del web browser ed utilizzano la
+				history per recuperare le pagine.
+				Questo può essere molto comodo quando si voglia verificare
+				l'effetto della pressione del pulsante Indietro nei form.
             </p>
             <p>
-                The frame methods need a little explanation.
-                By default a framed page is treated just like any other.
-                Content will be searced for throughout the entire frameset,
-                so clicking a link will work no matter which frame
-                the anchor tag is in.
-                You can override this behaviour by focusing on a single
-                frame.
-                If you do that, all searches and actions will apply to that
-                frame alone, such as authentication and retries.
-                If a link or button is not in a focused frame then it cannot
-                be clicked.
+				C'è bisogno di un piccolo chiarimento a proposito dei metodi per i frame.
+				Di default, una pagina all'interno di un frame viene trattata
+				esattamente come tutte le altre.
+				Le ricerche vengono effettuate su tutto il frameset e quindi
+				la pressione di un link funzionerà indipendentemente dal frame
+				che contiene il tag.
+				E' possibile sovrascrivere questo comportamento spostando il
+				focus su un singolo frame.
+				Così facendo, tutte le ricerche e le azioni come le autenticazioni
+				e i nuovi tentativi di esecuzione verranno applicate solo
+				al frame selezionato: se i link ed i pulsanti non si trovano nel
+				frame selezionato non possono essere premuti.
             </p>
             <p>
-                Testing navigation on fixed pages only tells you when you
-                have broken an entire script.
-                For highly dynamic pages, such as for bulletin boards, this can
-                be crucial for verifying the correctness of the application.
-                For most applications though, the really tricky logic is usually in
-                the handling of forms and sessions.
-                Fortunately SimpleTest includes
-                <a local="form_testing_documentation">tools for testing web forms</a>
-                as well.
+				Il collaudo della navigazione di pagine statiche fornisce solo
+				indicazioni di malfunzionamenti nell'intero script.
+				Per pagine altamente dinamiche, come ad esempio i bulletin board, 
+				questo può essere cruciale la verifica della correttezza dell'applicazione.
+				Tuttavia, per molte applicazioni, la parte veramente delicata della logica
+				si trova nella gestione di form e sessioni.
+				Fortunatamente SimpleTest include anche degli appositi <a local="form_testing_documentation">tool per il collaudo di
+				form</a>.
+                
             </p>
         </section>
-        <section name="request" title="Modificare la richiesta">
+        <section name="request" title="Modifiche alla richiesta e metodi di debug">
             <p>
-                Although SimpleTest does not have the goal of testing networking
-                problems, it does include some methods to modify and debug
-                the requests it makes.
-                Here is another method list...
+				Nonostante SimpleTest non abbia tra i suoi obiettivi quello di permettere il collaudo
+				dei problemi di rete, comprende anche alcuni metodi per modificare e debuggare le
+				richieste effettuate.
+				Di seguito un elenco dei metodi disponibili:
                 <table><tbody>
-                    <tr><td><code>getTransportError()</code></td><td>The last socket error</td></tr>
-                    <tr><td><code>showRequest()</code></td><td>Dump the outgoing request</td></tr>
-                    <tr><td><code>showHeaders()</code></td><td>Dump the incoming headers</td></tr>
-                    <tr><td><code>showSource()</code></td><td>Dump the raw HTML page content</td></tr>
-                    <tr><td><code>ignoreFrames()</code></td><td>Do not load framesets</td></tr>
-                    <tr><td><code>setCookie($name, $value)</code></td><td>Set a cookie from now on</td></tr>
-                    <tr><td><code>addHeader($header)</code></td><td>Always add this header to the request</td></tr>
-                    <tr><td><code>setMaximumRedirects($max)</code></td><td>Stop after this many redirects</td></tr>
-                    <tr><td><code>setConnectionTimeout($timeout)</code></td><td>Kill the connection after this time between bytes</td></tr>
-                    <tr><td><code>useProxy($proxy, $name, $password)</code></td><td>Make requests via this proxy URL</td></tr>
+                    <tr><td><code>getTransportError()</code></td><td>Restituisce l'ultimo errore del socket</td></tr>
+                    <tr><td><code>showRequest()</code></td><td>Esegue il dump della richiesta inviata</td></tr>
+                    <tr><td><code>showHeaders()</code></td><td>Esegue il dump dell'header ricevuto</td></tr>
+                    <tr><td><code>showSource()</code></td><td>Esegue il dump del contenuto HTML</td></tr>
+                    <tr><td><code>ignoreFrames()</code></td><td>Evita il caricamento del frameset</td></tr>
+                    <tr><td><code>setCookie($name, $value)</code></td><td>Imposta un cookie a partire dall'istante corrente</td></tr>
+                    <tr><td><code>addHeader($header)</code></td><td>Aggiunge sempre l'header specificato alla richiesta</td></tr>
+                    <tr><td><code>setMaximumRedirects($max)</code></td><td>Interrompe il test dopo il numero di richieste specificate</td></tr>
+                    <tr><td><code>setConnectionTimeout($timeout)</code></td><td>termina la connessione dopo l'intervallo specificato</td></tr>
+                    <tr><td><code>useProxy($proxy, $name, $password)</code></td><td>Esegue le richieste tramile il proxy URL specificato</td></tr>
                 </tbody></table>
-                These methods are principally for debugging.
+				Questi metodi sono utilizzati principalmente per debugging.
             </p>
         </section>
     </content>
     <internal>
         <link>
-            Successfully <a href="#fetch">fetching a web page</a>
+            <a href="#fetch">Recuperare una pagina</a>
         </link>
         <link>
-            Testing the <a href="#content">page content</a>
+            Collaudare il <a href="#content">contenuto di una pagina</a>
         </link>
         <link>
-            <a href="#navigation">Navigating a web site</a>
-            while testing
+            <a href="#navigation">Navigare un sito durante il test</a>
         </link>
         <link>
-            <a href="#request">Raw request modifications</a> and debugging methods
+            <a href="#request">Modifiche alla richiesta e metodi di debug</a>
         </link>
     </internal>
     <external>


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Bugs item #2820685, was opened at 2009-07-13 12:25
Message generated for change (Settings changed) made by pp11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547455&aid=2820685&group_id=76550

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unit test framework
Group: v1.0 (example)
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: generatePartial do not call parent::construc()

Initial Comment:
when generating a partial mock, constructor of mocked class is overriden, but parent construct is not called within it.

This is fatal becouse users of simpletest can use its clases contructor to initialize things. Like in CakePHP, where Model class initialize behaviours and all other sort of things in the constructor.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547455&aid=2820685&group_id=76550

Bugs item #2820721, was opened at 2009-07-13 13:36
Message generated for change (Settings changed) made by pp11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547455&aid=2820721&group_id=76550

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unit test framework
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Joan Ginard (lumenhaggen)
>Assigned to: Perrick Penet (pp11)
Summary: generatePartial do not call parent::construc()

Initial Comment:
when generating a partial mock, constructor of mocked class is overriden, but parent construct is not called within it.

This is fatal becouse users of simpletest can use its clases contructor to initialize things. Like in CakePHP, where Model class initialize behaviours and all other sort of things in the constructor.

----------------------------------------------------------------------

>Comment By: Perrick Penet (pp11)
Date: 2009-09-06 22:02

Message:
Could you please regenrate your patch against the SVN version of
SimpleTest. And also having a faling test case makes it a lot easier to get
you parch committed to the trunk.

Yours,
    Perrick


----------------------------------------------------------------------

Comment By: Joan Ginard (lumenhaggen)
Date: 2009-07-13 13:39

Message:
sorry for duplicate reporting at 

https://sourceforge.net/tracker/?func=detail&aid=2820691&group_id=76550&atid=547455
and
https://sourceforge.net/tracker/?func=detail&aid=2820685&group_id=76550&atid=547455

Is my first type with sourceforge project tracker. Close them if you want.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547455&aid=2820721&group_id=76550

Bugs item #2849129, was opened at 2009-09-02 15:47
Message generated for change (Comment added) made by pp11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547455&aid=2849129&group_id=76550

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Perrick Penet (pp11)
Summary: wrong style on simpletest.org

Initial Comment:
There is an error in http://www.simpletest.org/simpletest.css
How can't you see it so many time? :)

You have:

pre { font-family: monospaced;

But it should be (w/o "d"):

pre { font-family: monospace;


----------------------------------------------------------------------

>Comment By: Perrick Penet (pp11)
Date: 2009-09-06 20:08

Message:
Thanks for the report : it's been fixed now !

Yours,
     Perrick


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=547455&aid=2849129&group_id=76550