La maggior parte degli sviluppatori che hanno aggiunto funzionalità alla piattaforma edx hanno familiarità ModuloStoreTestCase. Se i tuoi test esercitano qualcosa relativo al contenuto del materiale didattico (anche se si tratta solo di creare un corso vuoto), l'ereditarietà da questa classe assicurerà che i dati vengano ripuliti correttamente tra i singoli test. Questo è estremamente prezioso, ma può anche essere uno spreco in molte situazioni. Durante l'hackathon della scorsa settimana, ho creato un'alternativa più veloce detto SharedModuleStoreTestCase.

a differenza di ModuloStoreTestCase, SharedModuleStoreTestCase solo ModuloStore pulizia presso il TearDownClass() livello. È pensato per essere impiegato in situazioni in cui uno o una piccola manciata di corsi possono essere inizializzati in anticipo e quindi condivisi in modalità di sola lettura in molti test. Questo modello di utilizzo si trova comunemente nei test LMS, che spesso ricreano semplicemente lo stesso percorso più e più volte nei loro impostare() metodi.

Impatto sulle prestazioni

Per avere un'idea dell'effetto che potrebbe avere, ho cambiato alcuni moduli di test come parte del mio lavoro di hackathon. Queste sono solo cifre approssimative, poiché si basano su un numero relativamente piccolo di test Jenkins. Detto questo, i risultati sono promettenti:

Compila il # Prove Prima Dopo shavasana, sedersi in silenzio; saluti; Delta
lms/djangoapps/ccx/tests/test_ccx_modulestore.py  5 38 secondi 4s -89%
lms/djangoapps/discussion_api/tests/test_api.py  409 2m 45s 51 secondi -69%
lms/djangoapps/teams/tests/test_views.py 152 1m 17s 33 secondi -57%

 

Quindi, come si convertono i propri test?

Rendere l'interruttore

La maggior parte delle classi che ereditano da ModuloStoreTestCase inizia qualcosa del genere:

Codice Python con evidenziazione della sintassi. Per visualizzare il codice sorgente, leggi il post del blog originale su http://swampcastle.org/2015/07/28/writing-faster-modulestore-tests.html

Se stai modificando auto.corso nelle tue funzioni di test individuali, allora questo è perfetto e dovresti continuare a usarlo ModuloStoreTestCase. Tuttavia, se stai configurando il corso solo una volta e lo tratti come di sola lettura nei tuoi test, ora puoi invece farlo:

Codice Python con evidenziazione della sintassi. Per visualizzare il codice sorgente, leggi il post del blog originale su http://swampcastle.org/2015/07/28/writing-faster-modulestore-tests.html

È importante che le operazioni di Django ORM rimangano attive impostare(). Tutti i modelli in cui crei setUpClass() deve essere eliminato manualmente nel tuo TearDownClass() metodo - SharedModuleStoreTestCase non li pulirà correttamente. Anche se stai attento, è comunque probabile che tu possa interrompere altri test nel sistema in modi imprevedibili perché fanno ipotesi sbagliate sulle sequenze e sugli ID che verranno creati quando impostano i loro dati. Questo può essere estremamente noioso per il debug.

Quando aggiorneremo a Django 1.8, sarai in grado di utilizzare setUpTestData() per eseguire in sicurezza l'inizializzazione a livello di classe dei modelli Django con la pulizia automatica. Attendi l'aggiornamento e inserisci le manipolazioni del modello impostare() per ora, anche se è un po' più lento.

Quali test devo convertire?

Il posto più semplice per cercare obiettivi di ottimizzazione dei test è il Rapporto sulla build del test di Jenkins. Fare clic su "Durata" per ordinare in base a quella colonna.

Screenshot del server Jenkins, che mostra i test che hanno richiesto più tempo per essere eseguiti.

Vogliamo principalmente puntare su test costosi che creano dati di corsi complessi (ad es. CCX) o hanno dati di corsi semplici ma molti, molti test (ad es. discussioni). La creazione anche del corso più semplice richiede circa 250-300 ms circa, il che si somma davvero quando si utilizzano strumenti come ddt che moltiplicano efficacemente il numero di test in una classe.

Da asporto generale

L'accesso al database è una parte costosa dell'esecuzione dei test e il ModuloStore ne è un ottimo esempio. lo spero SharedModuleStoreTestCase può essere uno strumento utile per ridurre i tempi di esecuzione dei test. Ma oltre a ciò, spero che capire perché funziona ci consentirà di progettare suite di test più veloci in generale.

Dave Ormsbee è un architetto senior presso edX. Questo post è stato originariamente pubblicato sul suo blog, Castello di palude.

Caricamento in corso