Più specificamente, per quanto riguarda l'ATDD (una sorta di BDD aromatizzato, o qualcuno che potrebbe argomentare ciò che in realtà era inteso in primo luogo da TDD) dovrebbe esserci un gran numero di test dell'interfaccia utente?
Come ho testato i miei componenti dell'interfaccia utente nel mio aroma del mese sul framework MCV lato client, trovo che non ho provato molto nei componenti stessi, ma solo nei moduli che usano.
Ad esempio, su un sito web di libri con Author s e Book s se sto testando la pagina di elenco Book per un autore, invece di verificare che gli elementi siano rappresentati correttamente nel componente (ad esempio li elementi per ogni libro, genitore ul , ecc.) Sposterei la logica in un modulo per recuperare quei Book s per uno specifico Author .
Per fare ulteriormente l'esempio, se ci fosse qualche logica per interagire con uno degli elementi Book resi in ul allora invece di controllare che un handler sia stato innescato vorrei solo assicurarmi che il gestore sia in fase di test correttamente.
Sembra che se provo il rendering dell'interfaccia utente di Author e il suo Book s sul lato client è troppo legato all'implementazione, e allo stesso modo con il gestore di eventi mi sposa al gestore di eventi in modo tale Non posso refactoring.
È questo il modo di pensare al lato client testare l'interfaccia utente? Forse ho solo bisogno di alcuni test di accettazione (ad es. Selenium) in questo caso per riempire gli spazi vuoti?