BACKGROUND: Sto lavorando a un progetto che utilizza Celery per pianificare attività che verranno eseguite in un determinato momento nel futuro. Questi compiti spingono lo stato della Final State Machine in avanti. Ecco un esempio:Eseguire un operatore Celery che si connette al DB di test Django
- Un futuro promemoria è programmato per essere inviato all'utente in 2 giorni.
- Quando quella operazione pianificata viene eseguita, viene inviata un'email, e il FSM è avanzata allo stato successivo
- Lo stato successivo è quello di programmare un promemoria per l'esecuzione in altri due giorni
- Quando questo compito viene eseguito, lo farà inviare un altro e-mail, far avanzare lo stato
- Etc ...
attualmente sto usando CELERY_ALWAYS_EAGER come suggerito da this SO answer
Il problema con l'utilizzo di questa tecnica nei test, è th al codice attività, che è pensato per essere eseguito in un thread separato, è in esecuzione nello stesso di quello che lo programma. Ciò fa sì che lo stato FSM non venga salvato correttamente e rendendo difficile il test. Non sono stato in grado di determinare cosa lo causa esattamente, ma sembra che nella parte inferiore dello stack di chiamate si stia salvando lo stato corrente, ma quando si ritorna allo stack delle chiamate, viene salvato uno stato precedente. Potrei dedicare più tempo a determinare cosa sta andando male quando il codice non sta eseguendo come dovrebbe, ma sembra più logico cercare di far funzionare il codice come dovrebbe e assicurarsi che stia facendo quello che dovrebbe.
DOMANDA: Vorrei quindi sapere se esiste un modo per eseguire un'impostazione completa di sedano che django può utilizzare durante un test. Se potesse essere eseguito in modo automatico, sarebbe ideale, ma anche un intervento manuale sarebbe meglio che dover testare il comportamento a mano. Sto pensando che qualcosa potrebbe essere possibile se inserisco una pausa nei test, eseguo il sedano per collegarmi al DB di test, continua i test di django. Qualcuno ha mai provato qualcosa del genere?
Sto supponendo che un'alternativa sarebbe scrivere alcuni di quelli che non usano il corridore di prova di Django e quindi utilizzare il database principale (di sviluppo), eseguendo il set-up manuale e il teardown dei dati. – Andres
Sì, questo è probabilmente l'approccio più semplice.Lo faccio per eseguire test contro un db di grandi dimensioni in cui i dispositivi non sono pratici. – joshua
Non so se è esattamente il tuo problema, ma ho avuto alcune condizioni di gara sul fatto che i task di Celery non passano attraverso il middleware Django, e quindi le operazioni di database non sono transazionali. Potrebbe essere la causa di strani comportamenti del database – geekazoid