Skip to main contentdfsdf

Sarah HL's List: Testing your apps

    • TDD employs five basic steps
    • First, you quickly add a test

    16 more annotations...

    • A [named user role] can [select/operate] [feature/function] so that [output] is [visible/complete/etc.] and leads to a Yes/No decision for user and developer 

       The Acceptance Test or Criteria should be more specific then the User Story description, and better define the customer's conditions of satisfaction. The Criteria should not include things like validation, boundary conditions, or "if then" statements.
      • Column domain value rules. For example, the Flavor column has allowable values of Chocolate, Vanilla, and Strawberry. 
      • Column default value rules. For example, the default value is Strawberry. 
      • Value existence rules. For example, there should always be a value of Flavor indicated (it can never be null). 
      • Row value rules. For example, the value of StartDate must be less than EndDate when EndDate is provided. 
      • Size rules. For example, a code in a column must always be two characters in length or a value in a VARCHAR column must be at least five characters in length
    • a high-profile web application
    • one of the developers from the other agile team walked up to my desk. I could tell immediately that something was wrong

    14 more annotations...

  • Jun 30, 09

    Très didactique pour expliquer le rôle des tests unitaires dans une application

    • Par rapport aux  tests manuels évoqués précédemment, la  granularité des tests unitaires est extrêmement fine
    • tests de recette, qui valident chaque fonctionnalité de l'application  dans son ensemble et permettent ainsi de mesurer l'avancement du projet

    3 more annotations...

    • une application ne sera réellement testable que si elle a été conçue pour cela
    • la conception doit tenir compte de la problématique du test
    • Il m'a signalé deux projets de BDD, qui permettent de faire le pont entre les demandes de tests fonctionnels, émis par des clients non-techniques, et les tests unitaires. Il s'agit de greenpepper (http://www.greenpeppersoftware.com/en/, Open Source et commercial ) et easyb (http://www.easyb.org/, logiciel libre).
    • Ces deux logiciels permettent de capturer les tests fonctionnels : on note les demandes de tests, puis on les convertis en un pseudo-langage. Une fois celui-ci écrit, le logiciel produit des tests fonctionnels à faire passer, et à exécuter automatiquement. Le concept est une couche qui ressemble aux tests unitaires, mais prend le problème à partir des clients, et non plus à partir des besoins de tests des couches base. Le concept est prometteur, notamment en conceptualisant les tests et les demandes clients, même si elles sont peut claires. Je me promets d'y consacrer un peu de temps.
    • Contrary to PHPUnit, lime tests are written in a procedural way.
    • Each test case is, by convention, introduced by a comment that explains the tests purpose.

    8 more annotations...

    • Il ne s'agit pas de s'en passer totalement : même les générateurs de code doivent être programmés par quelqu'un....
    • celui qui a produit le code

    5 more annotations...

    • En gros, le but d'un rapport de bug est de permettre au programmeur de voir le programme planter devant lui.
    • Les programmeurs ne sont pas des idiots : si le programme ne fonctionnait pas du tout, ils s'en seraient probablement déjà rendu compte. Comme ils n'ont rien remarqué, pour eux, il doit fonctionner. Donc, soit vous faites quelque chose d'une autre manière qu'eux, ou votre environnement est différent du leur. Ils ont besoin d'informations ; leur fournir ces informations et l'objectif d'un rapport de bug.

    13 more annotations...

1 - 14 of 14
20 items/page
List Comments (0)