Demonstration doctests
This is just an example of what a README text looks like that can be used with
the doctest.DocFileSuite() function from Python's doctest module.
Normally, the README file would explain the API of the module, like this:
 »> a = 1
 »> b = 2
 »> a + b
 3
Notice, that we just demonstrated how to add two numbers in Python, and 
what the result will look like.
En lisant ce fichier, doctest va interpréter les lignes préfixées par "»>" et vérifier que ce qui est retourné par l'évaluation de l'expression correspond à ce qui est écrit (ici, doctest va vérifier que l'évaluation de "a + b" renvoie bien 3).
Des tests orientés données, l'approche Fit.
Ward Cunningham propose dans son outil « fit » de rédiger les tests de validation dans un document, sans code. Son outil comprend un lanceur de test mais aussi un wiki embarqué, accessible via une interface Web. Dans ce wiki, les utilisateurs peuvent entrer, dans des tableaux, les jeux de données à fournir en entrée ainsi que les résultats attendus en sortie. Une autre possibilité, donnée aux utilisateurs, est d'entrer les jeux de données dans un tableur.
Des tests fonctionnels en phase avec les attentes de l'utilisateur, l'approche "BDD".
C'est en essayant d'enseigner l'approche TDD que Dan North s'est rendu compte que la plupart des développeurs acceptent volontiers d'écrire les tests avant le code mais se contentent de percevoir cette technique comme une façon de tester en même temps qu'on développe, sans percevoir ce qu'il s'agit en fait d'une méthode de développement. Pour faciliter cette compréhension de TDD, Dan North a étendu les notions de bases pour former Behavior Driven Development, une méthode sensée apporter aux développeurs tous les bénéfices d'une véritable approche de TDD.
Tests de non-régression.
Il s'agit de tests qui visent à assurer la non-régression d'une application. C'est à dire qu'une modification apportée à l'application ne rend pas erronés les comportements d'une application qui fonctionnaient avant la modification.
« Beta test ».
Le beta-test consiste à fournir une version quasi-finale de l'application (dite « version Beta ») à un large échantillon d'utilisateurs finaux. Ceci afin qu'ils rapportent les derniers bogues résiduels ou dans le cas d'une interface graphique, quelques améliorations ergonomique. La version livrée est estampillée « Beta » afin que les utilisateurs soient conscient qu'il ne s'agit pas le version finale et que le version présentée peut encore contenir des erreurs.
On parle de bêta ouverte ou de bêta fermée selon que cette version du logicielle soit accessible à tous les utilisateurs potentiels ou seulement à un groupe restreint.

LispWorks CAPI/Fenêtre de choix
Certains éléments d'une interface de la fenêtre contient des collections d'objets, par exemple pour les lignes de boutons, des listes de noms de fichiers, et des groupes d'éléments de menu. Ces éléments sont connus dans les CAPI que les collections.
Dans la plupart des collections, des éléments peuvent être sélectionnés par l'utilisateur - par exemple, une rangée de boutons. Les collections dont les éléments peuvent être sélectionnés sont connus comme des choix. Chaque bouton dans une rangée de boutons est soit cochée ou décochée, montrant quelque chose sur l'état de l'application - peut-être que les graphismes de couleur sont allumés et le son est coupé. Cet état de sélection ont été à peu près aussi le résultat d'un choix de l'utilisateur lors de l'exécution fait la demande, ou par défaut les choix effectués par l'application elle-même.
Le CAPI fournit un moyen commode de produire des groupes d'articles à partir de laquelle les collections et les choix peuvent être faits. La classe abstraite collection fournit un moyen de spécifier un groupe d'éléments. Le groupe de sous-classe choice fournit des éléments sélectionnables, où vous pouvez spécifier dans quel état ils sont en première, et ce qui se passe lorsque la sélection est modifiée. Les sous-classes collection et choice, utilisées pour la production de certains types d'éléments regroupés, sont décrits dans les sections qui suivent.
Tous les choix décrits dans ce chapitre ne peut être donnée une fonction d'impression via le mot-clé :print-function. Cela vous permet de contrôler la manière dont les articles dans l'élément sont affichées. Par exemple, en passant l'argument 'string-capitalize à :print-function serait de mettre la première lettres de tous les mots du texte en majuscule.
Certains des exemples dans ce chapitre nécessitent les fonctions test-callback et Bonjour qui ont été introduites dans Créer une fenêtre simple.

Photographie/Fabricants/Holga
Les appareils en matière plastique vendus sous la marque Holga sont fabriqués en Chine.

Vérification et tests
Vérification et tests/Introduction
Vérification et tests/Intégration dans le processus de développement

Photographie/Fabricants/Samsung/Samsung EX1

Photographie/Fabricants/Sigma/Sigma DP1x

Joby
Photographie/Fabricants/Joby
La société JOBY a été fondée en 2005. Elle a son siège social à San Francisco, Californie, et possède diverses agences en Suisse, en Chine, à Singapour, etc. Elle fabrique divers produits innovants comme les différents modèles de GorillaPod destinés aux appareils photographiques.

Photographie/Fabricants/Kinderman
Kindermann
Photographie/Fabricants/Kinderman/Kinderman 50 PV

Introduction au test logiciel/Tests unitaires

Dans ce chapitre, nous allons voir ce qu'est un "" (ou "TU"). Il s'agit du test le plus couramment utilisé et le plus important. Nous verrons comment créer des tests unitaires pour votre code et comment les utiliser. Nous verrons enfin les limitations de ces tests.
Introduction aux tests unitaires.
L'objectif d'un test unitaire est de permettre au développeur de s'assurer qu'une unité de code ne comporte pas d'erreur de programmation. C'est un "test", donc les vérifications sont faites en exécutant une petite partie (une « "unité" ») de code. En programmation orientée objet, l'unité est la classe. Un test est donc un programme qui exécute le code d'une classe pour s'assurer que celle-ci est correcte, c'est-à-dire que ses résultats correspondent à ce qui est attendu dans des assertions prédéfinies (ex : codice_1 doit être vrai).
Concrètement, un test, c'est du code. À chaque classe d'une application, on associe une autre classe qui la teste.
Les différences entre un test unitaire et un sont que le TU :
Les frameworks de type xUnit.
Pour écrire des tests unitaires, vous avez à votre disposition des frameworks qui vont vous faciliter l'écriture des tests. Vous n'aurez plus qu'à écrire les classes de tests et c'est le framework qui se chargera de les trouver, de les lancer et de vous donner les résultats ou les erreurs qui ont été détectées.

Photographie/Fabricants/Sony/Sony Cyber-shot DSC-W200

Photographie/Fabricants/Sony/Sony Cyber-shot DSC-W90

Photographie/Fabricants/Sony/Sony Cyber-shot DSC-W80

LispWorks/La classe choice
LispWorks CAPI/Push-button-panel
LispWorks CAPI/Fenêtre de choix/La classe choice

Cette section décrit les sous-classes immédiate de choice qui peut être utilisé pour construire des button-panel. Si vous avez un groupe de plusieurs boutons, vous pouvez utiliser l'élément approprié button-panel de préciser tous comme un groupe, plutôt que d'utiliser des push-button ou des check-button pour indiquer chacun d'eux séparément. Il y a trois éléments tels que: push-button-panel , check-button-panel et radio-button-panel. Les spécificités de chacun sont discutés dans les sections ci-dessous.

LispWorks CAPI/Fenêtre de choix/La classe choice/Push-button-panel