La libreria di riferimento di Python

Previous: 5.4 test Up: 5.4 test Next: 5.4.2 Eseguire test usando

---

5.4.1 Scrivere Unit Tests per il package test

È preferibile che i test per il package test utilizzino il modulo unittest e seguano alcune linee guida. Per prima cosa tutti i nomi dei metodi di test devono iniziare con "test_" come anche il nome del modulo. Questo è necessario affinchè il test driver li riconosca come metodi di test. Inoltre, non dovrebbe essere inclusa alcuna stringa di documentazione. Al loro posto si dovrebbe utilizzare un commento (come "# Le funzioni di test restituiscono solo True o False") per fornire documentazione al metodo di test. Questo viene fatto perché le stringhe di documentazione (NdT: docstring) se esistono vengono stampate e perciò non risulta chiaro quale test sia in esecuzione.

Spesso viene utilizzata una costruzione basilare tipo questa:

import unittest
from test import test_support

class MyTestCase1(unittest.TestCase):

    # Usate solo setUp() e tearDown() se necessario
    
    def setUp(self):
        ... codice da utilizzare per preparare i test ...
	
    def tearDown(self):
        ... codice da eseguire per la ripulitura dopo i test ...

    def test_feature_one(self):
        # Test feature one.
	... codice di test ...

    def test_feature_two(self):
        # Test feature two.
        ... codice di test ...
         
    ... altri metodi di test ...
    
class MyTestCase2(unittest.TestCase):
    ... stessa struttura di MyTestCase1 ...
    
... altre classi di test

def test_main():
    test_support.run_unittest(MyTestCase1,
                              MyTestCase2,
                              ... elencate altri test ...
                             )

if __name__ == '__main__':
    test_main()

Questo codice permette alla suite di test di essere eseguita sia da test.regrtest sia autonomamente come script.

Lo scopo dei test di regressione è quello di provocare la ``rottura'' del codice, facendolo andare in errore. Per cui è necessario seguire alcune linee guida:

• La suite di test deve provare tutte le classi, funzioni e costanti. Questo include non solo l'API esterna da presentare al codice cliente, ma anche il codice "privato".
• É preferibile la verifica whitebox(verificare il codice che viene esaminato al momento stesso in cui i test vengono scritti). I test blackbox (testare solo l'interfaccia utente da pubblicare) non sono abbastanza completi da assicurare la verifica di tutti i casi marginali e di contorno.
• Assicuratevi che tutti i possibili valori vengano provati, inclusi quelli non validi. Questo vi garantisce non solo che tutti i valori corretti vengano accettati, ma che anche i valori scorretti vengano gestiti correttamente.
• Esaurite tutti i percorsi possibili all'interno del codice. Testate le ramificazioni e quindi adattate l'input per assicurarvi che vengano scelti più percorsi possibili all'interno del codice.
• Aggiungete un test esplicito per ogni difetto scoperto nel codice testato. Questo assicura che l'errore non si verifichi di nuovo nel caso il codice venga modificato in futuro.
• Assicuratevi di far pulizia dopo i test (come chiudere e cancellare tutti i file temporanei).
• Importate solo i moduli necessari e fatelo il prima possibile. Questo minimizza le dipendenze esterne dei test e riduce i comportamenti anomali causati dagli effetti secondari dell'importazione dei moduli.
• Tentate di massimizzare il riutilizzo del codice. In alcune occasioni, i test varieranno per qualcosa piccolo come il tipo di input utilizzato. Minimizzate la duplicazione del codice derivando una classe di test di base con una classe che specifica l'input:

  class TestFuncAcceptsSequences(unittest.TestCase):
  
      func = mySuperWhammyFunction
  
      def test_func(self):
          self.func(self.arg)
  
  class AcceptLists(TestFuncAcceptsSequences):
      arg = [1,2,3]
  
  class AcceptStrings(TestFuncAcceptsSequences):
      arg = 'abc'
  
  class AcceptTuples(TestFuncAcceptsSequences):
      arg = (1,2,3)
  

---

La libreria di riferimento di Python

Previous: 5.4 test Up: 5.4 test Next: 5.4.2 Eseguire test usando

---

Release 2.3.4, documentation updated on 21. maggio 2005.