Template:Dev test

From zeroincombenze
Jump to: navigation, search
Tb arrow up.jpg Lang english.png


Testing procedura e moduli Odoo

I test della procedura e dei moduli sono parti piuttosto complessi da scrivere e da gestire ma sono estremamente importanti per la certificazione e l'uso del software nel progetto zeroincombenze®


Concetti principali

Ci sono 4 tipi di test

  • test funzionale yaml
  • test veloci (fast_suite)
  • test funzionali (sanity_checks)
  • test fuori contesto

Ulteriore documentazione è disponibile nelle pagine:


Test funzionale yaml

Sono test basati sul metalinguaggio yaml e sono indipendenti dal linguaggio python. Sono eseguiti prima dei test python, prima dell'installazione di un modulo e ad ogni aggiornamento, se il DB contiene i dati demo. Il risultato è scritto nel file di log. Sono attivabili anche tramite opzioni al riavvio del servizio.

Richiedono l'installazione della dipendenza yaml in installazione Odoo


Test veloci (fast_suite)

Sono test scritti python ed eseguiti prima dell'installazione di un modulo, se il DB contiene dati demo. Il risultato è scritto nel file di log.

Richiedono l'installazione della dipendenza unitest2 in installazione Odoo

Test funzionali (sanity_checks)

Sono test scritti python ed eseguiti prima dell'installazione di un modulo e ad ogni aggiornamento, se il DB contiene dati demo. Il risultato è scritto nel file di log.

Richiedono l'installazione della dipendenza unitest2 in installazione Odoo

Test Fuori contesto

Sono test eseguiti fuori contesto ambiente Odoo (ovvero senza i parametri cr e uid), tramite riga di comando, indipendentemente dal servizio.

Devono appoggiarsi direttamente alla libreria unitest2 standard di python.


Parametro yaml fast suite sanity check fuori contesto
Ambiente Servizio server Servizio server Servizio server Nessuno
Requirement DB con demo data DB con demo data DB con demo data Nessuno
Attivazione Installazione/Aggiornamento modulo Installazione Installazione/Aggiornamento modulo Manuale
Ripetibilità Riavvio servizio No Riavvio servizio Comando
Linguaggio yaml python python python


Test funzionale yaml

Sono test basati sul metalinguaggio yaml e sono indipendenti dal linguaggio python. Permettono di testare funzionalità del modulo.

Caratteristiche

  1. La directory dove sono cercati i test è ./test del modulo da testare; i file hanno estensione .yml
  2. Nella directory ./test può essere presente il file di definizione package __init__.py, solitamente vuoto
  3. Se presente, il file __init__.py della directory ./test deve contenere l'import di tutti i file con i test in formato from . import test_file1, test_file2 ...
  4. Nel file __openerp__.py del modulo deve essere dichiarato il parametro test.

Per il posizionamento dei file vedere Struttura dei moduli.

Ulteriori dettagli su serializzazione yaml

Esempio di dichiarazione in __openerp__.py:

  'test': [
       'test/mytest_1.yml',
       'test/mytest_2.yml',
   ],

Il comando di attivazione è:

[sudo] service odoo restart -i MODULO --test-enable -d TEST --log-level=test

dove

  • MODULO è il nome del modulo da testare
  • TEST è il nome del database


Test veloci (fast_suite)

Sono test scritti python ed eseguiti prima dell'installazione di un modulo, se il DB contiene dati demo. Il risultato è scritto nel file di log.

Richiedono l'installazione della dipendenza unitest2 in installazione Odoo

Caratteristiche:

  1. La directory dove sono cercati i test è ./tests del modulo da testare
  2. Nella directory ./tests deve essere presente il file di definizione package __init__.py
  3. Il file tests/__init__.py deve contenere l'import di tutti i file con i test in formato from . import test_file1, test_file2 ...
  4. Per la V7 è necessario inserire, nel file tests/__init__.py, la dichiarazione della variabile fast_suite con la lista dei singoli test
  5. Dalla V8 sono eseguiti tutti i test, indipendentemente dalla dichiarazione
  6. I singoli test devono iniziare con test_; si consiglia vivamente la stessa regola anche per i file
  7. Ogni file deve contenere un classe derivata da openerp.tests.common
  8. Le classi sono: TransactionCase, SingleTransactionCase e RpcCase
  9. Nel file di test non deve essere inserita la dichiarazione di fine classe
  10. Escludendo i simboli '_' e le differenza maiuscolo/minuscolo, il nome del test da eseguire ed il nome della classe devono essere identici.

Per il posizionamento dei file vedere Struttura dei moduli.

Esempio tests/__init__.py:

  fast_suite: [
       test_1,
       test_2,
   ],

Il comando di attivazione è:

[sudo] service odoo restart -i MODULO --test-enable -d TEST --log-level=test

dove

  • MODULO è il nome del modulo da testare
  • TEST è il nome del database

Test funzionali (sanity_checks)

Sono test scritti python ed eseguiti prima dell'installazione di un modulo e ad ogni aggiornamento, se il DB contiene dati demo. Il risultato è scritto nel file di log.

Richiedono l'installazione della dipendenza unitest2 in installazione Odoo Caratteristiche:

  1. La directory dove sono cercati i test è ./tests del modulo da testare
  2. Nella directory ./tests deve essere presente il file di definizione package __init__.py
  3. Il file tests/__init__.py deve contenere l'import di tutti i file con i test in formato from . import test_file1, test_file2 ...
  4. Per la V7 è necessario inserire, nel file tests/__init__.py, la dichiarazione della variabile checks con la lista dei singoli test
  5. Dalla V8 sono eseguiti tutti i test, indipendentemente dalla dichiarazione
  6. I singoli test devono iniziare con test_; si consiglia vivamente la stessa regola anche per i file
  7. Ogni file deve contenere un classe derivata da openerp.tests.common
  8. Le classi sono: TransactionCase, SingleTransactionCase e RpcCase
  9. Nel file di test non deve essere inserita la dichiarazione di fine classe
  10. Escludendo i simboli '_' e le differenza maiuscolo/minuscolo, il nome del test da eseguire ed il nome della classe devono essere identici.

Per il posizionamento dei file vedere Struttura dei moduli.

Esempio tests/__init__.py:

  checks: [
       test_1,
       test_2,
   ],

Il comando di attivazione è:

[sudo] service odoo restart -i MODULO --test-enable -d TEST --log-level=test
[sudo] service odoo restart -u MODULO --test-enable -d TEST --log-level=test

dove

  • MODULO è il nome del modulo da testare
  • TEST è il nome del database

Se il modulo è quello di base, prima dell'esecuzione dei test funzionali, sono eseguiti i test funzionali del core di Odoo in /opt/odoo/8.0/openerp/tests

Scrittura codice test

Test python (fast suite e sanity check)

La classe TransactionCase è da usarsi per eseguire i test in modo indipendente uno dall'altro.

La classe SingleTransactionCase è da usarsi tutti i test in un'unica transazione.

La classe RpcCase è riservata per test RPC.

I test terminano con un rollback delle attività in modo da non lasciare residui di dati e sono eseguiti tramite utente amministratore.


Esempio:

from openerp.tests.common import SingleTransactionCase

class Test_main(SingleTransactionCase):
 
    def test_00 (self)
         ...
 
    def test_01 (self)
         ...
 

Vedere anche Odoo 8.0 Testing modules e Come eseguire i test


Costanti utilizzabili nei test

Per l'esecuzione dei test sono disponibili alcuni valori di costanti

Nome Modello Note
account.a_recv account.account Conto dei clienti
account.a_pay account.account Conto dei fornitori
account.ova account.account Conto IVA a debito (da clienti)
account.iva account.account Conto IVA a credito (da fornitori)
account.o_income account.account Ricavi da vendite
account.o_expense account.account Costi in fattura
account.bnk account.account Conto bancario
account.cash account.account Conto di cassa


Test fuori contesto dai moduli)

I test dei moduli sono importanti perché sono eseguiti all'interno dell'ambiente Odoo (con i parametri cr e uid).

A volte è necessario effettuare test esterni ai moduli. In questo caso i testi devono essere attivati tramite riga di comando.

In questo caso il test deve contenere le righe di attivazione e deve appoggiarsi direttamente alla libreria unitest2 standard di python.

Rispetto ai test OpenERP occorre definire i metodi setUp() e tearDown() e attivare l'esecuzione del test dal main.

Esempio

class myTest (unittest2.TestCase)
 
    def setUp (self)
        cls.cr = cls.cursor()
        cls.uid = openerp.SUPERUSER_ID
 
 
    def tearDown (self)
        cls.cr.rollback()
        cls.cr.close()
 
 
    def test_00 (self)
         ...
 
    def test_01 (self)
         ...
 
class main:
    # Run main if executed as a script
    if __name__ == "__main__":
        unittest2.main()

Esecuzione test

32px warning.jpg
L'esecuzione del test blocca temporaneamente il normale funzionamento del server e ne può rallentare il funzionamento durante l'esecuzione

I test possono essere eseguiti soltanto sulla macchina di sviluppo.

Nell'esempio che segue sostituire:

MODULO       con il nome esatto del modulo da testare
TEST_RESULT  con il nome del file log di test di risultato
DEVELOPMENT  con il nome del database in cui eseguire il test

Il parametro --test-report non funziona, occorre modificare il file ~/.openerp_serverrc

Deve esistere la directory /opt/openerp/testlog

[sudo] service openerp stop                # stop servizio
[sudo] su - openerp -s /bin/bash           # divento utente openerp
vim  ~/.openerp_serverrc                   # modifico il parametro logfile
  logfile = /opt/openerp/testlog/TEST_RESULT.log
./lp/openerp/openerp-server --log-level=test -i MODULO --test-enable -d DEVELOPMENT 

Il log riporta, oltre i soliti messaggi, i messaggi marcati TEST ed eventuali messaggi di tipo ERROR. Se il modulo è installato si può usare l'opzione -u invece che -i (in questo caso non sono eseguiti i test dichiarati in fast_suite).


Utility per esecuzione di tutti i test

Con la V7 è possibile eseguire tutti i test di validazione con l'utility test_odoo. L'esecuzione consigliata è:

test_odoo -all -av

che permette di eseguire tutti i test su un'istanza concorrente, senza fermare il servizio Odoo. Per maggiori dettagli digitare:

test_odoo -h


Test per validazione travis

Travis.ci attiva i test di funzionalità tramite maintainer quality tool. Il file di scripte è test_server e crea il DB openerp_template per l'esecuzione.

La configurazione è scritta nel file travis.yml con le seguenti regole generali e le seguenti regole per python. La validazione del file yaml può essere effettuata qui.

Le variabili specifiche di Odoo da dichiarare sono:

name descrition default value Value in local test environment
EXCLUDE N/D None None
INCLUDE N/D Inferred by TRAVIS_BUILD_DIR Odoo installation paths from /etc/openerp-server.conf
INSTALL_OPTIONS Odoo option swithes on DB installation (i.e. --logfile) None None
ODOO_REPO Odoo repository. odoo/odoo local/openerp
OPTIONS N/D
SERVER_EXPECTED_ERRORS Defalut value 0
TRAVIS_BUILD_DIR Module pathname (automatic, do not change)
UNIT_TEST N/D
VERSION Must be 7.0 or 8.0

Altri strumenti di test

Zeroincombenze punta ad un elevato livello di testing del codice. Sono in studio anche test per altre caratteristiche del software. Sonon in fase di studio:

  • locust → sistema di test massivo sul server; permette di simulare un elevato numero di client
  • mock → modulo di test già installato e utilizzato da sviluppatori Odoo di terze parti
  • anybox.recipe → tool che permette di installare e provare più versioni di Odoo per test di sviluppo o CI
  • travis-ci → sito collegato con github per la Continuous Integration
  • coveralls → sito collegato con github per l'analisi del coverage
  • buildout → tool per creare installare più versioni di Odoo per per test di sviluppo o CI
  • virtualenv → tool che permette di creare ambienti python diversi e di gestire le dipendenze tra loro
  • distutils → package per il supporto e la costruzione di moduli python
  • buildbot → Framework per Continuous Integration

Vedere Tassonomia test python