Produits Entr'ouvert » Hobo

Pour des tests en grandeur nature je signale cela : https://pypi.org/project/pytest-rabbitmq/

Benjamin Dauvergne a écrit :

Pour des tests en grandeur nature je signale cela : https://pypi.org/project/pytest-rabbitmq/

Ça ne représente aucune nécessité dans le cadre de ce ticket, je signale juste pour plus tard (voir pour ouvrir un nouveau ticket suite à celui-ci).

Nicolas Roche a écrit :

J'ai raté cette piste, merci.

Je pensais attraper les exceptions standards pour lever à la place des 'CommandError':
- IndexError pour test_set_idp() utilisée sans Authentic configuré
- AttributeError pour cook() utilisée avec permissive non déclaré
- AttributeError pour set_theme() utilisée sans que les thèmes soient installés

Je n'ai pas vraiment le contexte mais réutiliser les exceptions de la lib standard est une idée acceptable pour des petites fonctions se rapprochant d'une fonction de base genre émettre IndexError/KeyError sur une erreur dans get_truc(i). Mais s'en servir pour propager des erreurs à travers un graphe d'appel c'est une mauvaise idée, il vaut mieux dans ce cas prévoir une exception spécifique.

En fait, cette 3ème erreur fait que le test pseudo 'grandeur nature' ne passe pas sur Jenkins.
Est-ce que cela reste envisageable de pousser un tel test ?

Désolé je ne comprends pas vraiment là, poste une trace peut-être.

Merci benj, j'essaye d'être plus explicite :

Les 3 levées d'exceptions décrites ci-dessus seraient atteignables directement via la ligne de commande

$ hobo-manage cook recipe.json

Cf les 2 'TODO' dans les 2 patchs ci-dessus,
et la trace dans jenkins : https://jenkins2.entrouvert.org/job/hobo-wip/job/wip%252F32886-add-tests-for-cook/1/testReport/junit/tests_schemas/test_cook/test_cook_ozwillo/

La seconde question (erreur avec tox, désolé d'avoir embrouillé le ticket) c'est de savoir si c'est envisageable de modifier jenkins pour prendre en compte les thèmes. Je dis ça parce qu'il faut que les thèmes ne soient pas installés (via make install) pour reproduire la trace jenkins ci-dessus.

Nicolas Roche a écrit :

Merci benj, j'essaye d'être plus explicite :

Les 3 levées d'exceptions décrites ci-dessus seraient atteignables directement via la ligne de commande
[...]

Oui oui mais donc on devrait avoir une méthode cook générique qui génère des CookError et la commande doit convertir ça en CommandError proprement.

Cf les 2 'TODO' dans les 2 patchs ci-dessus,
et la trace dans jenkins : https://jenkins2.entrouvert.org/job/hobo-wip/job/wip%252F32886-add-tests-for-cook/1/testReport/junit/tests_schemas/test_cook/test_cook_ozwillo/

En tout cas pour celle-ci ça me parait parfait pour une CookError('unknown theme %s' % theme_id) justement mais pas dans ce ticket, ici pour que ça fonctionne je dirai qu'il faut juste avoir une fixture qui crée un répertoire y met un faux thème et qui définit settings.THEMES_DIRECTORY pour que hobo.theme.utils.get_themes() fonctionne.

La seconde question (erreur avec tox, désolé d'avoir embrouillé le ticket) c'est de savoir si c'est envisageable de modifier jenkins pour prendre en compte les thèmes. Je dis ça parce qu'il faut que les thèmes ne soient pas installés (via make install) pour reproduire la trace jenkins ci-dessus.

Réponse dans mon dernier paragraphe, non le test doit être indépendant du paquet publik-base-theme.

Nicolas Roche a écrit :

voici donc deux patchs qui ajoutent des tests pour cook.py :

• tests/cook.py pour les tests unitaires
• tests_schemas/cook.py : ajoute un scénario plausible côté serveur

Pour faire des répertoires temporaires tu as une fixure tmpdir[1] qui gère tout pour toi (mais ça renvoie des objets Path de pathlib il faut faire str() dessus avant des les utiliser dans du code normal).

¹ https://docs.pytest.org/en/latest/tmpdir.html

• test_handle c'est un peu exagéré on ne descend pas aussi bas dans nos tests en général, enfin on va le garder
• Ça c'est assez étrange :

      assert str(command.check_action.mock_calls) == expected1
  

  Il me semble que tu peux directement instancier des objets call() et qu'ils sont comparables¹ tant que leurs arguments le sont. Ça devrait rendre tout ça plus lisible.

¹ Et oui

In [1]: from mock import call

In [2]: call('a', object) == call(u'a', object)
Out[2]: True

C'est possible de pas avoir de expected et de mettre directement la valeur sur la ligne assert ? C'est plus lisible je trouve.

Nicolas Roche a écrit :

voilà

Ça ne doit pas être les bons patchs :

    expected = [call('recipe_me.json')] 

• receipe -> recipe
• plutôt qu'un mock d'open posé le fichier dans un tmpdir

  with tmpdir / 'recipe.json' as path:
      with path.open() as fd:
          fd.write(json.dumps(recipe))
      command.run_cook(str(path))
  

  
  je ne suis pas fan d'utiliser mock quand ce n'est pas nécessaire et qu'on peut tester le vrai code
• plus court que

      value = Variable.objects.get(name='foo').value
      label = Variable.objects.get(name='foo').label
      assert value == 'bar'
      assert label == 'foo'
  

  
  on peut
  

  variables = Variable.objects
  ...
      var = variables.get(name='foo')
      assert var.value == 'bar'
      assert var.label == 'foo'
  

  
  et
  

      value = Variable.objects.get(name='foo').value
      ordered_dump = json.dumps(json.loads(value), sort_keys=True)
      assert  ordered_dump == '{"key1": "bar", "key2": "baz"}'
  

  
  plutôt
  

  var = variables.get(name='foo')
  assert var.json == {"key1": "bar", "key2": "baz"}
  

• je ne comprends pas cette remarque, la virer si ce n'est plus d'actualité

      """ 
      code redondant ?
        service_type=obj_type,
        service_pk=obj.id,
      """ 
  

• je n'avais pas remarqué avant mais je ne vois pas le rapport avec ozwillo (faudrait renommer ça autrement)

Je veux bien mais je ne vois pas de quels lignes tu parles.

c'est dans hobo/environment/management/commands/cook.py::create_site()
et c'était à propos de ma remarque sur du code redondant :

        for variable_name in variables.keys():
            label = variables[variable_name].get('label')
            variable, created = Variable.objects.get_or_create(name=variable_name,
                    service_type=obj_type,
                    service_pk=obj.id,
                    defaults={'label': label or variable_name})
            variable.service_type = obj_type  # <-- ici
            variable.service_pk = obj.id      # <-- et là

Nicolas Roche a écrit :

c'est dans hobo/environment/management/commands/cook.py::create_site()
et c'était à propos de ma remarque sur du code redondant :
[...]

Oui tout à fait c'est redondant :)