Jak poprawnie testować pole do wprowadzania adresu…

Testowanie pola wprowadzania email obejmuje sprawdzanie funkcjonalności, walidacji, wygody użytkowania i bezpieczeństwa.

Testowanie funkcjonalne:

Wprowadzanie poprawnych adresów:
- 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.демо (w celu obsługi zinternationalizowanych nazw domen - IDN)
Wprowadzanie niepoprawnych adresów:
- Brak @: testexample.com
- Kilka @: test@@example.com
- Niepoprawny format domeny: test@example
- Brak nazwy użytkownika: @example.com
- Znaki specjalne w nazwie użytkownika: te!st@example.com, te#st@example.com
- Znaki specjalne w domenie: test@exa!mple.com
- Długi adres (sprawdzenie limitów): a_very_long_email_address_that_exceeds_typical_limits@example.com (sprawdzić limity zgodnie ze specyfikacją lub zdrowym rozsądkiem)
- Adres z spacjami: test @example.com
- Adres z niepoprawną składnią: test@.com, test.@example.com
- Adres z adresem IP zamiast domeny (jeśli nie jest obsługiwany): test@[192.168.1.1]
- Adres z cyrylicą (jeśli nie jest obsługiwany IDN): тест@пример.рф
Puste pole: Wysyłanie formularza z pustym polem.

Walidacja:

Sprawdzanie zgodności wprowadzonych danych ze składnią email (wyrażenia regularne).
Wyświetlanie użytkownikowi komunikatów o błędach przy wprowadzaniu niepoprawnych danych.
Sprawdzanie dokładności i zrozumiałości komunikatów o błędach.
Sprawdzanie, czy formularz nie jest wysyłany przy obecności błędów walidacji.

Użyteczność & UI/UX:

Fokus na polu przy ładowaniu strony (jeśli to stosowne).
Tekst podpowiedzi z przykładem formatu (np. user@example.com).
Obsługa autouzupełniania przez przeglądarkę.
Obecność etykiety (<label>) dla pola.
Użytkownik nie może wprowadzić niedozwolonych znaków (jeśli taka logika jest na froncie).
Jeśli jest maska wprowadzania, sprawdzenie jej działania.

Bezpieczeństwo:

Sprawdzanie podatności na XSS: wprowadzanie skryptów, tagów HTML (<script>alert('XSS')</script>) w polu.
Sprawdzanie iniekcji (SQL/NoSQL): wprowadzanie specyficznych znaków, które mogą wpłynąć na zapytania do bazy danych (' OR '1'='1).
Limiting ilości prób (jeśli formularz wysyła email lub wykonuje zasobożerne działania): sprawdzenie ograniczeń liczby prób wysłania z jednego IP lub użytkownika.

Automatyzacja:

Pisanie testów jednostkowych dla funkcji walidacji email.
Pisanie testów integracyjnych dla sprawdzania działania pola w kontekście formularza.
Pisanie testów E2E dla pełnego scenariusza użycia formularza z polem email.

Przykład kodu dla testu jednostkowego walidacji:

// Zakładamy, że mamy funkcję validateEmail
function validateEmail(email) {
  const re = /\S+@\S+\.\S+/; // Prosty przykład wyrażenia regularnego
  return re.test(email);
}

// Testy jednostkowe z użyciem Jest
describe('validateEmail', () => {
  test('powinno zwrócić true dla poprawnego email', () => {
    expect(validateEmail('test@example.com')).toBe(true);
    expect(validateEmail('firstname.lastname@example.com')).toBe(true);
  });

  test('powinno zwrócić false dla niepoprawnego email', () => {
    expect(validateEmail('testexample.com')).toBe(false);
    expect(validateEmail('test@example')).toBe(false);
    expect(validateEmail('@example.com')).toBe(false);
  });

  test('powinno zwrócić false dla pustego ciągu', () => {
    expect(validateEmail('')).toBe(false);
  });
});

Przykład testu E2E z użyciem Cypress:

// cypress/integration/email_field.spec.js
describe('Pole email', () => {
  it('prawidłowo waliduje i wyświetla błąd dla niepoprawnego wejścia', () => {
    cy.visit('/your-form-page'); // URL strony z formularzem
    cy.get('#email-input').type('invalid-email'); // Wprowadzanie niepoprawnego email
    cy.get('button[type="submit"]').click(); // Kliknięcie przycisku wysyłki (może być konieczne jawne wywołanie walidacji)
    cy.get('.error-message').should('be.visible').and('contain', 'Niepoprawny format email'); // Sprawdzenie komunikatu o błędzie
  });

  it('pozwala na wysłanie formularza z poprawnym emailem', () => {
    cy.visit('/your-form-page');
    cy.get('#email-input').type('valid@example.com');
    cy.get('button[type="submit"]').click();
    // Dalsze sprawdzenia: np. przekierowanie, komunikat o sukcesie
    cy.url().should('include', '/success'); // Przykład sprawdzenia URL po wysłaniu
  });
});

Tabela z przykładami przypadków testowych:

ID	Działanie użytkownika	Oczekiwany rezultat
TC_01	Wprowadzenie `test@example.com`	Pole uznaje za poprawne. Formularz wysyła się (jeśli wszystkie pola są wypełnione).
TC_02	Wprowadzenie `invalid-email`	Pole uznaje za niepoprawne. Wyświetla się komunikat o błędzie.
TC_03	Puste pole i próba wysłania formularza	Pole uznaje za niepoprawne (jeśli jest obowiązkowe). Wyświetla się komunikat o błędzie.
TC_04	Wprowadzenie `test@example.co.uk`	Pole uznaje za poprawne.
TC_05	Wprowadzenie `<script>alert('XSS')</script>`	Skrypt nie powinien zostać wykonany. Pole powinno być oczyszczone lub zwalidowane.

Należy również uwzględnić specyficzne wymagania projektu (np. obsługa określonych stref domenowych, czułość na wielkość liter), testowanie na różnych urządzeniach i przeglądarkach.

Jak poprawnie testować pole do wprowadzania adresu e-mail?