Pourquoi Fit / FitNesse?

Question

Quel est le point d'utiliser Fit / FitNesse au lieu des tests d'intégration de style xUnit? Il a une syntaxe vraiment étrange et très peu clair à mon avis.

Est-il vraiment que les propriétaires de faire de ce produit écrire des tests? Ils ne seront pas! Il est trop compliqué pour eux. Alors pourquoi devrait-Fit / FitNesse?

Mise à jour Il est donc tout à fait approprié pour les tests business règles seulement?

Answer 1

Le tout est de travailler non-programmeurs, souvent même complètement les personnes non techniques comme les utilisateurs de perspective d'une application métier, sur quelle application doit faire et puis le mettre dans les tests. Alors qu'ils devraient pouvoir faire des tests de travail est certainement trop compliqué pour eux, pour discuter de tables de données d'échantillon rempli en exemple Mot. Et la grande chose est, contrairement à la spécification traditionnelle, ces documents en direct avec votre application, car des tests automatisés vous obligent à les mettre à jour.

Voir Introduction à Fit et Fit Flux de travail par James Shore et suivre les liens vers le reste de la documentation si vous voulez.

---

Mise à jour: Cela dépend de ce que vous entendez par des règles d'affaires? ;-) Certaines personnes comprendraient très étroitement (comme dans les règles d'affaires moteurs, etc.), d'autres --- très large.

Comme je le vois, Fit est un outil qui vous permet d'écrire vers le bas des affaires (comme dans le domaine) des cas d'utilisation avec des exemples riches réalistes dans un document, que les utilisateurs finaux ou des experts du domaine (dans certains domaines) peuvent comprendre, vérifier et discuter. En même temps, ces exemples sont en forme lisible par machine afin qu'ils puissent être utilisés pour conduire les tests automatisés, vous n'écrire le document entièrement par vous-même, ni les requre de le faire. Au contraire, il est un produit de callaboration et la discussion qui reflète la compréhension de plus en plus de ce que l'application va faire, des deux côtés. Des exemples deviennent plus riches que vous progressez et plus de cas d'angle sont résolus.

Quelle application va faire, comment, est important. Il est une forme de spécification fonctionnelle. À ce titre, il est assez large et pas vraiment organisé par modules, mais plutôt des scénarios d'utilisation.

Les tests qui sortent des exemples tester le comportement externe d'application dans des aspects importants du point de vue commercial. Oui, vous pouvez appeler des règles métier. Mais permet de regarder l'exemple de Diego Jancic de notation de crédit, juste avec un petit twist. Que faire si une partie du document en forme est 1) la liste des attributs et leurs scores, puis 2) fournissant des données clients et contrôle des résultats, alors qui sont les règles d'affaires réelles: table de pointage (attributs et leurs scores) ou la logique d'application de calcul du score pour chaque client (basé sur la table de pointage)? Et qui sont testés?

Fit / essais FitNesse semblent plus appropriés pour les tests d'acceptation. D'autres tests (quand vous ne se soucient pas de la coopération avec les clients, les utilisateurs, les experts du domaine, etc., vous voulez juste pour automatiser les tests) sera probablement plus facile d'écrire et de maintenir de manière plus traditionnelle. xUnit est agréable pour les tests unitaires et des tests de api. Chaque cadre Web devrait avoir un outil pour tester l'application Web / service intégré dans son cycle modify-conception-test-deploy, par exemple. django a son petit client de test. Vous avez beaucoup à choisir.

Et vous pouvez toujours écrire votre propre outil (ou modifier de préférence PRÉEXISTANTES) pour un meilleur ajustement (jeu de mots) des tests dans votre domaine d'intérêt particulier.

---

Une pensée plus générale. Il est souvent (pas toujours !!!) mieux encoder vos tests, « règles métier » et à peu près tout, dans une certaine forme de données bien définies qui est interprétée par une pièce simple, générique de code. Ensuite, il est facile d'utiliser les données d'une autre manière: générer de la documentation, la migration vers nouveau framework de test, l'application port nouvel environnement / langage de programmation, utiliser pour vérifier la conformité avec certaines règles externes ou un autre système (il suffit d'utiliser votre imagination). Il est beaucoup plus difficile de tirer ces informations à partir du code, par exemple. simples tests unitaires ou des règles hardcoded d'affaires.

Fit stocke les cas de test sous forme de données. En format très spécifique en raison de la façon dont il est destiné à être utilisé, mais quand même. Votre domaine des tests spécifiques peuvent utiliser différents formats comme simples CSV, JSON ou YAML.

Answer 2

L'idée est que vous (le programmeur) définit un format facile à comprendre, comme une feuille Excel. Ensuite, le propriétaire du produit entre l'information qui est difficile à comprendre pour les personnes qui ne sont pas dans l'entreprise ... et vous validez simplement que votre code fonctionne comme le bon de commande en cours d'exécution Fit attend. La manière utilisée dans xUnit, peut être utilisé pour les programmeurs comme une entrée pour facile à comprendre ou à des informations simples. Si vous allez avoir besoin d'entrer dans un grand nombre d'exemples étranges avec plusieurs champs dans votre test xUnit, il est devenu difficile à lire.

Imaginez un cas où vous devez décider de donner un prêt à un client, en fonction de l'âge, Couple marié / Célibataire, Montant des enfants, salaire, activité, ... En tant que programmeur, vous ne pouvez pas écrire cette information; et un gestionnaire de risque ne peut pas écrire un test xUnit.

Answer 3

Aide à réduire la redondance dans la régression et les tests de bogue. Construire repository gérer des cas de test. Sa construction comme une fois et utiliser pour toujours.