2013-06-19 4 views
5

Ho la seguente configurazione:Esecuzione di un lavoratore Sedano in unittest

  • Django-Sedano progetto compito A registri foo
  • Progetto B: Usa send_task di sedano chiamare foo
  • progetto A e progetto B hanno la stessa configurazione: SQS, msgpack per la serializzazione, gzip, ecc
  • Ciascun progetto vive su un repository github diversa

Ho le chiamate testate dall'unità a "foo" nel progetto A, senza utilizzare Celery, solo foo(1,2,3) e si asserisce il risultato. So che funziona.

Ho testato l'unità che send_task nel progetto B invia i parametri corretti.

Quello che non sto testando, e ho bisogno di un vostro consiglio, è l'integrazione tra i due progetti. Mi piacerebbe avere un unittest che sarebbe:

  • Avviare un lavoratore nel contesto del progetto A
  • Invio di un'attività utilizzando il codice di progetto B
  • affermare che il lavoratore ha iniziato nella prima fase si l'attività, con i parametri inviati nel secondo passaggio e che la funzione foo ha restituito il risultato previsto.

Sembra possibile hackerarlo utilizzando il sottoprocesso di python e analizzare l'output del worker, ma è brutto. Qual è l'approccio raccomandato ai test unitari in casi come questo? Qualche frammento di codice che potresti condividere? Grazie!

+0

Aiutaci a capire, perché vuoi testare cosa succede dal lato dei lavoratori? Non è sufficiente testare dal lato chiamante, e se i risultati della risposta corretta dichiarano il test un successo? –

risposta

1

Non sono sicuro se valga la pena di testare esplicitamente il meccanismo di trasporto (ovvero l'invio dei parametri dell'attività tramite il sedano) utilizzando un test unitario. Personalmente, vorrei scrivere la mia prova come segue (può essere suddivisa in diverse unit test):

  • Utilizzare il codice progetto B per generare un compito con i parametri del campione.
  • Codifica i parametri dell'attività utilizzando lo stesso metodo utilizzato da Celery (ovvero decapitando i parametri o codificandoli come JSON).
  • Decodificare nuovamente i parametri dell'attività, verificando che non si sia verificata alcuna corruzione.
  • Chiamare la funzione compito, assicurandosi che produca il risultato corretto.
  • Eseguire la stessa sequenza di codifica/decodifica per i risultati della funzione compito.

Usando questo metodo, si sarà in grado di testare che le opere di generazione

  • Il compito come previsto
  • La codifica & decodifica dei parametri delle attività e dei risultati funziona come previsto

Se necessario, è ancora possibile testare in modo indipendente il funzionamento del meccanismo di trasporto mediante un test di sistema.