Sobes.tech
Junior

Comment tester correctement le champ de saisie de l'adresse e-mail?

sobes.tech IA

Réponse de l'IA

La validation du champ de saisie de l'email inclut la vérification de la fonctionnalité, la validation, l'utilisabilité et la sécurité.

Tests fonctionnels :

  • Saisie d'adresses valides :
    • test@example.com
    • firstname.lastname@example.com
    • email@subdomain.example.com
    • firstname+lastname@example.com
    • email@example.co.uk
    • email@example.museum
    • email@example.name
    • email@example.демо (pour le support des noms de domaine internationalisés - IDN)
  • Saisie d'adresses non valides :
    • Absence de @ : testexample.com
    • Plusieurs @ : test@@example.com
    • Format de domaine incorrect : test@example
    • Absence de nom d'utilisateur : @example.com
    • Caractères spéciaux dans le nom d'utilisateur : te!st@example.com, te#st@example.com
    • Caractères spéciaux dans le domaine : test@exa!mple.com
    • Adresse longue (vérification des limites) : a_very_long_email_address_that_exceeds_typical_limits@example.com (vérifier les limites selon la spécification ou le bon sens)
    • Adresse avec espaces : test @example.com
    • Adresse avec syntaxe incorrecte : test@.com, test.@example.com
    • Adresse avec une adresse IP au lieu du domaine (si non supporté) : test@[192.168.1.1]
    • Adresse avec cyrillique (si non supporté IDN) : тест@пример.рф
  • Champ vide : Envoi du formulaire avec le champ vide.

Validation :

  • Vérification de la conformité des données saisies à la syntaxe de l'email (expressions régulières).
  • Affichage de messages d'erreur à l'utilisateur lors de la saisie de données non valides.
  • Vérification de la précision et de la clarté des messages d'erreur.
  • Vérification que le formulaire ne s'envoie pas en cas d'erreurs de validation.

Usabilité & UI/UX :

  • Mise au focus sur le champ lors du chargement de la page (si pertinent).
  • Texte de placeholder avec un exemple de format (par exemple, user@example.com).
  • Support de l'autocomplétion par le navigateur.
  • Présence d'une étiquette (<label>) pour le champ.
  • L'utilisateur ne peut pas saisir de caractères non autorisés (si cette logique est présente en front-end).
  • Si une masque de saisie est présente, vérifier son fonctionnement.

Sécurité :

  • Vérification contre les vulnérabilités XSS : saisie de scripts, balises HTML (<script>alert('XSS')</script>) dans le champ.
  • Vérification contre les injections (SQL/NoSQL) : saisie de caractères spécifiques pouvant influencer les requêtes à la base de données (' OR '1'='1).
  • Limitation du taux (si le formulaire envoie un email ou effectue des actions gourmandes en ressources) : vérifier la restriction du nombre de tentatives d'envoi depuis une même IP ou utilisateur.

Automatisation :

  • Rédaction de tests unitaires pour les fonctions de validation de l'email.
  • Rédaction de tests d'intégration pour vérifier le fonctionnement du champ dans le contexte du formulaire.
  • Rédaction de tests E2E pour vérifier le scénario complet d'utilisation du formulaire avec le champ email.

Exemple de code pour un test unitaire de validation :

// Supposons que nous ayons la fonction validateEmail
function validateEmail(email) {
  const re = /\S+@\S+\.\S+/; // Exemple simple d'expression régulière
  return re.test(email);
}

// Tests unitaires avec Jest
describe('validateEmail', () => {
  test('devrait retourner true pour un email valide', () => {
    expect(validateEmail('test@example.com')).toBe(true);
    expect(validateEmail('firstname.lastname@example.com')).toBe(true);
  });

  test('devrait retourner false pour un email invalide', () => {
    expect(validateEmail('testexample.com')).toBe(false);
    expect(validateEmail('test@example')).toBe(false);
    expect(validateEmail('@example.com')).toBe(false);
  });

  test('devrait retourner false pour une chaîne vide', () => {
    expect(validateEmail('')).toBe(false);
  });
});

Exemple de test E2E avec Cypress :

// cypress/integration/email_field.spec.js
describe('Champ de saisie de l'email', () => {
  it('valide correctement et affiche une erreur pour une entrée invalide', () => {
    cy.visit('/votre-page-formulaire'); // URL de la page avec le formulaire
    cy.get('#email-input').type('email-invalide'); // Entrée d'un email invalide
    cy.get('button[type="submit"]').click(); // Cliquer sur le bouton d'envoi
    cy.get('.error-message').should('be.visible').and('contain', 'Format d'email incorrect'); // Vérification du message d'erreur
  });

  it('permet de soumettre le formulaire avec un email valide', () => {
    cy.visit('/votre-page-formulaire');
    cy.get('#email-input').type('valide@example.com');
    cy.get('button[type="submit"]').click();
    // Vérifications supplémentaires : redirection, message de succès, etc.
    cy.url().should('include', '/succès'); // Vérification de l'URL après envoi réussi
  });
});

Tableau avec des exemples de cas de test :

ID Action de l'utilisateur Résultat attendu
TC_01 Entrer test@example.com Le champ est considéré comme valide. Le formulaire est soumis (si tous les champs sont remplis).
TC_02 Entrer email-invalide Le champ est considéré comme invalide. Un message d'erreur s'affiche.
TC_03 Laisser le champ vide et essayer d'envoyer le formulaire Le champ est considéré comme invalide (si obligatoire). Un message d'erreur s'affiche.
TC_04 Entrer test@example.co.uk Le champ est considéré comme valide.
TC_05 Entrer <script>alert('XSS')</script> Le script ne doit pas être exécuté. Le champ doit être nettoyé ou validé.

Il faut également prendre en compte les exigences spécifiques du projet (par exemple, support pour certains domaines, sensibilité à la casse), tester sur différents appareils et navigateurs.