Bienvenue sur la page communauté Sooth ERP, où vous pouvez poser vos questions. Inscrivez-vous (via le login de Mantis)

Bienvenue dans la communauté Sooth ERP.

Vous pouvez posez ici vos questions ou fournir des réponses aux autres membres de la communauté.

Tests unitaires

0 votes

Pour avoir eu un bref échange avec un contributeur sur le sujet, je me suis brièvement penché sur la question pour comprendre un peu le principe (que je découvre pour l'occasion).

Donc si on envisage une refonte un peu profonde de certaines choses, c'est vrai que c'est un principe qui permet d'éviter de casser le code.

Mais en pratique comment implanter la chose car il faudrait que chaque fonction soit testée, mais lorsqu'on aborde des opérations complexes ou des sujets abstraits (comment s'assurer qu'un arrondi est valable dans TOUS les cas de figure ), ça devient ardu.

Concernant les outils Php Unit semble aller de soi car c'est un peu un standard tout de même.

J'ai testé (pour les non réfractaires à l'interface graphique) Netbeans qui semble bien intégrer l'outil.

Problème pour le moment : Netbeans n'aime pas l'usage de fichiers avec des encodages non homogènes (avec raison d’ailleurs!). Il faudrait d'abord tout passer en utf8. Mais c'est sur la "to do list"...

Des avis à partager ?

 

posté Mai 12, 2013 dans la catégorie Divers par Yves (3,790 points)
modifié Mai 13, 2013 par Yves

1 Réponse

0 votes

Par analogie avec d'autres ERP, les tests unitaires sont souvent utilisés dans le cadre de validation de modules spécifiques ou plugins par exemples.

Très utiles notamment lors d'upgrade voir update parfois.

L'écriture des tests unitaires est un véritable développement en parallèle surtout pour un ERP.

Les tests peuvent être effectués à plusieurs niveaux :

  • Montée en charge
  • Nombre de connexions
  • Nombre de réf. différentes dans la DB...
  • Etc...

Sauf erreur de ma part, les tests unitaires sont souvent proposés à des utilisateurs finaux spécifiques afin de valider une solution customisée mais n'est généralement pas proposée avec les sources, surtout en version communautaire.

A évaluer : Est-il utile aujourd'hui d'écrire des tests unitaires ? ou favoriser le développement de la communauté pour rassembler un maximum de retour d'expérience et/ou cas différents ?

répondu Mai 13, 2013 par Torcos (300 points)
Oui, j'ai bien saisi que l'écriture des tests est un véritable développement et qu'il est visiblement préférable de les mettre en place dès le début dans un processus de création.

Par contre quand on reprend du code en l'état on n'a plus ce choix est l'implémentation peu s'avérer complexe si la structure du code ne s'y prête pas.

Par contre (à moins que l'on ne parle pas exactement de la même chose), je voyais ça au contraire au niveau du code source (enfin pas à l'intérieur du code lui-même, mais dans un dossier test accompagnant la source) et plutôt destiné à l'usage exclusif des développeurs.

Aujourd'hui je ne pense pas que ce soit utile (en tout cas pas la priorité), mais le jour où l'on va réagencer voire refactorer un peu le code sur certains points, ça pourrait le devenir pour s'assurer que l'on ne casse pas le code, c'est comme ça que je l'ai saisi.

En l’occurrence le sujet est venu concernant les problèmes de calculs d'arrondis (qui si on fouille un peu apparaissent dans pas mal ERP).
Le premier problème est avant tout de limiter les affichages d'arrondis au strict nécessaire (= strict légal sur la TVA dans une facture) sinon c'est la quadrature du cercle entre arrondis des sommes et sommes des arrondis.

Cette parenthèse faite, Sooth ERP gagnerait je pense à utiliser des DECIMAL au lieu des DOUBLE pour les tarifs dans la BDD et à remplacer les calculs php par des fonctions bcmath pour, à la base, avoir quelque chose de solide au niveau calcul.
C'est là qu'interviennent les tests unitaires éventuels, car on commence à changer certaines choses en profondeur, il est prudent de s'assurer que l'on ne casse pas le code.
Ça n'oblige pas pour autant à implémenter les tests sur l'ensemble de Sooth ERP...

Ceci étant dit, je ne vois toujours pas comment implémenter un test qui s'assure que QUEL QUE SOIT les entrées (tarifs, qté, remises etc), les calculs d'arrondis finaux sont justes...
...