Tester et intégrer un module de progiciel
Amener un développement de progiciel jusqu'à la production : les trois environnements, les niveaux de test, l'import des données et ses rejets, et le plan de retour arrière.
- 25 cartes
- 5 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
- Comprendre
Quelques cartes du deck
Environnement de recette : de quoi s'agit-il ?
Voir la réponse
Installation proche de la production, tenue à part des utilisateurs réels, où l'on essaie une modification sur une copie récente de leurs données avant de la livrer.
Un module qui passe sur une base vide peut échouer sur les vraies données et sur les autres modules installés. La recette montre ces échecs sans conséquence.
Ce test d'un module échoue avec
AssertionError: 25.0 != 20. Que faut-il corriger ?
```python
def test_total(self):
partner = self.env['res.partner'].create({'name': 'Dupont'})
loan = self.env['library.loan'].create({
'partner_id': partner.id,
'line_ids': [(0, 0, {'price': 10}), (0, 0, {'price': 15})],
})
self.assertEqual(loan.total, 20)`- La valeur attendue : 10 plus 15 font 25, c'est le test qui est faux
- Le calcul du champ : il doit renvoyer 20 pour que le test passe
- Rien : un test unitaire qui échoue peut rester sans conséquence
- L'assertion :
assertTrue(loan.total)passerait alors et suffirait
Voir la réponse
La valeur attendue : 10 plus 15 font 25, c'est le test qui est faux
Le message donne la valeur obtenue (25.0) et la valeur attendue (20) : le code additionne bien. Affaiblir l'assertion pour que le test passe le viderait de sa valeur.
Le trajet d'une modification traverse trois environnements, dans cet ordre : …, … puis ….
Voir la réponse
Le trajet d'une modification traverse trois environnements, dans cet ordre : développement, recette puis production.
On développe là où l'on peut casser, on éprouve sur une copie réaliste, et seulement ensuite on touche à l'installation que les utilisateurs emploient vraiment.
Test d'intégration : de quoi s'agit-il ?
Voir la réponse
Test qui vérifie que le module fonctionne avec le standard et les autres modules installés, en suivant un scénario qui traverse plusieurs d'entre eux.
Un module peut être juste seul et casser son voisin : un champ obligatoire ajouté à un modèle du standard bloque la facturation, ce que seul un scénario complet révèle.
Après l'installation du module de prêt en production, plus aucune facture ne se valide. Quelle cause et quelle solution ?
- La base de recette est trop ancienne ; la recharger depuis la production règle le problème, et il suffit de revalider les factures ensuite
- Le manifeste n'a pas de numéro de version ; en ajouter un puis réinstaller le module, ce qui débloque la validation des factures
- Un champ rendu obligatoire sur un modèle du standard bloque la facturation ; lui donner une valeur par défaut ou retirer l'obligation, puis tester avec la facturation
- Les droits du groupe comptable sont trop larges ; les restreindre au strict nécessaire pour que les factures se valident de nouveau
Voir la réponse
Un champ rendu obligatoire sur un modèle du standard bloque la facturation ; lui donner une valeur par défaut ou retirer l'obligation, puis tester avec la facturation
Les factures du standard sont créées sans connaître le champ ajouté : s'il est obligatoire, la création échoue. Le test d'intégration avec la facturation n'avait jamais été passé.