2010-06-14 13 views
1

Je réalise qu'il y a une question similaire ici, mais celle-ci a une approche différente: j'ai une application django qui fait des requêtes sur des données indexées avec djapian; Je voudrais écrire des tests unitaires pour le composant de recherche de cette application, et, évidemment, j'aurais besoin du module de paramétrage django et de toutes les connexions avec la base de données active, donc le lanceur de test fourni par django semble idéal. Cependant, le cadre de test django crée une base de données factice et je détesterais de vider toutes mes données à un appareil et ensuite l'indexer (les tests prendraient pour toujours !);Comment faire pour que le framework de test django soit lu depuis la base de données en ligne?

Mes données ne sont pas à risque car les tests ne liraient qu'à partir de la base de données, alors, comment cela pourrait-il être réalisé? -Je suis nouveau à ce test de l'unité entière, donc la solution d'écriture d'un nouveau testeur J'ai lu dans cette question similaire ne m'éclaire pas un peu, du moins pas sans quelques détails

Répondre

2

Lire le test cas pour djapian J'ai trouvé quelque chose de vraiment intéressant: ce que ces gars font est d'utiliser la méthode setUp pour la classe TestCase: ils créent un objet puis utilisent la méthode update pour l'indexeur, donc ils ont un document pour rechercher et façon d'écrire des tests de requêtes contrôlées! Pour les curieux, la méthode ressemble à quelque chose comme ceci:

def setUp(self): 
    p = Person.objects.create(name="Alex") 

    for i in range(self.num_entries): 
     Entry.objects.create(author=p, title="Entry with number %s" % i, text="foobar " * i) 

    Entry.indexer.update() 

Je pense que ce serait faire, mais il faut se rappeler que je teste un petit moteur de recherche ici, donc cette solution pourrait être la solution facile; Cependant, je ne peux pas formuler d'objection, donc si vous avez une réponse qui vous aidera à définir une stratégie pour tester ce type de webapps en python en général, c'est plus que bienvenue!

-Je pense que je vais régler quelque chose comme ça pour l'instant (je voulais tester la latence des requêtes avec une base de données entièrement peuplée aussi, mais je pense que je pourrais le faire plus tard avec des tests de banc Funkload)

EDIT: Ok, pour être fidèle à une solution pour toute personne intéressée, j'ai rencontré un autre problème: l'index xapian (comme indiqué dans le commentaire). Pour le résoudre, j'ai créé un testeur par défaut qui a changé l'index xapian de production pour un index de test (un plus petit, créé avec un script de gestion). Ce coureur est assez simple:

def custom_run_tests(test_labels, verbosity=1, interactive=True, extra_tests=[]): 
    """Set the test indices""" 
    settings.CATEGORY_CLASSIFIER_DATA = settings.TEST_CLASSIFIER_DATA  
    return run_tests(test_labels, verbosity, interactive, extra_tests) 

Et, pour l'utiliser, j'ai simplement ajouté un paramètre:

TEST_RUNNER = 'search.tests.custom_run_tests' 

J'abandonné l'approche mentionnée ci-dessus (création des documents dans le setUp) pour des raisons de performance et de lisibilité : pour tester la base de données j'avais besoin d'une quantité décente de documents avec du texte (un paragraphe ou deux), donc j'ai fini par créer un fixture pour cela (j'ai utilisé une commande de gestion qui créait les documents dans la base de données réelle). les dans un fichier, puis les supprimer). Donc, à la fin, je n'ai pas lu du tout en direct et utilisé plutôt des appareils de test créés avec un script un peu hacky et un coureur personnalisé, et ce n'était pas si difficile :)