2009-07-29 10 views
5

Abbiamo un progetto Python che vogliamo iniziare a testare usando buildbot. I suoi test unitari includono test che dovrebbero funzionare solo su alcune piattaforme. Quindi, abbiamo test che dovrebbero passare su tutte le piattaforme, test che dovrebbero essere eseguiti solo su una piattaforma specifica, test che dovrebbero passare sulle piattaforme A, B, C e test che passano su B e D.Come distribuire ed eseguire test unitari specifici per piattaforma?

Cos'è il modo migliore per farlo? Le suite semplici sarebbero una seccatura, dal momento che, come descritto, ogni test può avere un elenco diverso di piattaforme di destinazione. Ho pensato di aggiungere decoratori "@ run_on" e "@ignore_on" che avrebbero abbinato le piattaforme ai metodi di test. C'è qualcosa di meglio?

risposta

0

Abbiamo deciso di andare con decoratori che, utilizzando il modulo della piattaforma e gli altri, controllare se i test dovrebbero essere eseguiti e se non semplicemente lascia passare (anche se, abbiamo visto che python2.7 ha già nel suo tronco un'eccezione SkipTest che potrebbe essere sollevata in questi casi, per ignorare il test).

+1

SkipTest è anche nel naso, con l'opzione --no-skip molto utile. – Almad

0

Sembra un luogo pratico per un caricatore di test.

Partenza http://docs.python.org/library/unittest.html#unittest.TestLoader.loadTestsFromName

Se si forniscono alcune convenzioni di denominazione idonei probabilmente si possono creare suite in base alle convenzioni di denominazione di test.

Se ho prova A che esegue su AIX, Linux (tutte) e 32 bit di Windows, prova B che gira su Windows 64, Linux e Solaris 64, e test di C che gira su tutto, ma HPUX e il test D che funziona su tutto ... Quale possibile convenzione di denominazione è lì per questo?

class TestA_AIX_Linux2_Win32(unittest.TestCase): 

class TestB_Win64_Linux64_Solaris(unittest.TestCase): 

class TestC_AIX_Linux2_Win32_Win64_Linux64_Solaris(unittest.TestCase): 

class TestD_All(unittest.TestCase): 

La parte difficile è "non HP/UX". Evitare la logica negativa ti semplifica la vita. In questo caso, è sufficiente elencare tutti i sistemi operativi che non sono HP/UX. L'elenco è piuttosto breve e cresce lentamente.

I test "Tutti" sono semplicemente una ricerca di testo separata che viene unita alla lista di test della piattaforma corrente per creare una suite completa.

Si potrebbe provare qualcosa di simile

class TextC_XHPUX(unittest.TestCase): 

tua regola di corrispondenza di testo è normalmente "_someOSName"; le tue eccezioni sarebbero un filtro di testo strano per scherzare con il nome "_X".

"Non è possibile avere un elenco positivo di sistemi operativi. Che cosa succede se aggiungiamo un nuovo sistema operativo? Dobbiamo rinominare ogni test per includerlo esplicitamente?" Sì. Il nuovo mercato dei sistemi operativi è lento ad evolversi, non è così doloroso da gestire.

L'alternativa consiste nell'includere informazioni all'interno di ciascuna classe (ad esempio una funzione a livello di classe) o un decoratore e utilizzare un caricatore di classe personalizzato che valuti la funzione a livello di classe.

+0

Non capisco come aiuterà esattamente. Se ho il test A eseguito su AIX, Linux (tutti) e Windows a 32 bit, test B eseguito su Windows 64, Linux 64 e Solaris e test C eseguito su tutto tranne HPUX e test D che funziona su tutto ... quale possibile convenzione di denominazione esiste per questo? – abyx

2

In un paio di occasioni ho usato questo approccio molto semplice in moduli di test:

import sys 
import unittest 

if 'win' in sys.platform: 
    class TestIt(unittest.TestCase): 
     ... 

if 'linux' in sys.platform: 
    class TestIt(unittest.TestCase): 
     ...