Il DBB per il test della componente "Server" - parte 1

Prosecuzione del post sul paradigma Client/Server

Lo sviluppatore non testa ... falso! "auto-testa"

Come scritto sul post precedente, realizzare una componente server presuppone OBBLIGATORIAMENTE di investire delle risorse per il testing.

Ci sono vari modi di fare test, e per esperienza una volta che il codice viene scritto difficilmente si torna allo sviluppo del test.

Ma in realtà questo tempo viene già "sprecato". Facciamo un esempio.
Tipicamente lo sviluppo "agile" con ROR (o altri framework) prevedere che:

1. si inizia a scrivere del codice, magari prendendo spunto da precendenti progetti o ricerche su google
2. si avvia il server e si controlla se non si sono fatti errori di sintassi
3. si avvia il browser e si naviga l'applicazione
4. si compilano un po di dati
5. si ricarica la pagina
6. ci si imbatte in un errore
7. trovato si vede sul log il punto sul sorgente che ha dato errore e si torna al punto 1

Quindi c'è già un tempo impiegato a di navigare, immettere dati, ricaricare pagine.

Inoltre più aumentano le funzionalità, maggiore è il tempo "perso" a caricare e ricaricare i dati.

Si pensi ad esempio a quante volte si ridigitano credenziali di accesso o testi di ricerca

Il BDD - behavior-driven development

Utilizzare correttamente i sistemi di BDD permettono
- di ottimizzare i tempi di sviluppo (riducendo i tempi di auto-test)
- di garantire la stabilità del codice
- di aumentare il livello di coinvolgimento del cliente e degli altri team

Nel nostro esempio, dovendo partire a sviluppare la componente server, si è partiti dalla definizione delle funzionalità (behavior) e degli scenari d'uso:

#encoding: utf-8
Feature: Login
  Per verificare che il login funzioni correttamente
  Come operatore devo poter accedere alle funzioni riservate
  Come cliente devo poter vedere solo i miei documenti
  Il sistema viene precaricato con 3 operatori, 2 utenti e 4 documenti
   
  Scenario: Login Operatore
    Given a user "operator1" with password "test1234"
    When he logs whit username and password
    Then he should navigate page "operators" and have 3 records 
    And  he should navigate page "customers" and have 2 records
    And  he should navigate page "settings"
    And  he should navigate page "documents" and have 4 records

  Scenario: Login Cliente
    Given a user "customer1" with password "test1234"
    When he logs whit username and password
    Then he should see olny his documents
    And  he shouldn't navigate page "documents" 
    And  he shouldn't navigate page "customers" 
    And  he shouldn't navigate page "users"
    And  he shouldn't navigate page "settings"

e ancora

#encoding: utf-8
Feature: Caricamento documenti
  Per verificare il corretto funzionamento dei documenti
  Come operatore dovrei essere in grado di caricare un nuovo tipo di documento ed   associarlo ad un cliente
  Come Cliente dovrei essere in grado di vedere i documenti a me associati e scaricarli
Il sistema viene precaricato con 3 operatori, 2 utenti e 4 documenti
Scenario: Caricamento documenti da operatore1
    Given a user "operator1" with password "test1234"
    When he logs whit username and password
    Then he should navigate page "customers"
    And he should navigate customer "azienda1"
    And he should upload an "F24" using "file1"
    And customer should have assigned an "F24"

  Scenario: Caricamento documenti da operatore2
    Given a user "operator2" with password "test1234"
    When he logs whit username and password
    Then he should navigate page "customers"
    And he should navigate customer "azienda2"
    And he should upload an "Bilancio" using "file2"
    And customer should have assigned an "Bilancio"

  Scenario: Accesso a documenti da cliente
    Given a user "customer1" with password "test1234"
    When he logs whit username and password
    Then he should have a list of documents that include an "F24_init"