Dezvoltarea UI în JavaScript folosind principiile TDD

Am avut o mulțime de probleme încercând să găsesc cea mai bună modalitate de a urma în mod corespunzător principiile TDD în timp ce dezvoltam UI în JavaScript. Care este cel mai bun mod de a face asta?

Este mai bine să separați imaginea de funcțional? Dezvoltați mai întâi elementele vizuale, apoi scrieți teste și apoi codificați funcționalitatea?

0

7 răspunsuri

0
adăugat

Am găsit arhitectura MVP foarte potrivită pentru scrierea interfețelor UI testabile. Clasele Prezentator și Modelul pot fi pur și simplu 100% testate pentru unități. Trebuie doar să vă faceți griji în legătură cu Vizualizare (care ar trebui să fie un strat subțire, subțire, care declanșează evenimente către Prezentator) pentru testarea UI (cu Selenium etc.)

Rețineți că vorbesc despre utilizarea în întregime a MVP în contextul UI, fără a fi necesară trecerea la server. Interfața dvs. UI poate avea propriul prezentator și model care trăiește în întregime pe partea clientului. Prezentatorul conduce logica interacțiunii/validării UI etc. în timp ce modelul păstrează informațiile de stare și oferă un portal către backend (unde puteți avea un model separat).

De asemenea, ar trebui să aruncați o privire la tehnica TDD Prezentator prima .

0
adăugat

Ceea ce fac este să-i dau Domului să vadă dacă primesc ceea ce mă aștept. Un efect secundar extraordinar este că, în ceea ce privește efectuarea rapidă a testelor, puteți face rapid și aplicația.

Tocmai am lansat un set de instrumente open source care va ajuta foarte mult cu JavaScript tdd. Este o compoziție a mai multor instrumente open source, care vă oferă o aplicație de lucru de tip backbone de lucru.

Oferă comenzi unice pentru a rula: serverul de server dev, browserul de testare pentru browserul de iasomie, testul de jasmin js-test-driver multi-test și concatenarea/minificarea pentru JavaScript și CSS. De asemenea, este afișată o versiune neînfrânată a aplicației dvs. pentru depanare de producție, precompilă șabloanele de ghidon și suportă internaționalizarea.

Nu este necesară nicio configurare. Pur și simplu funcționează.

http://github.com/davidjnelson/agilejs

0
adăugat

Sunt pe cale să încep să fac Javascript TDD pe un nou proiect la care lucrez. Planul meu actual este să folosiți qunit pentru a efectua testarea unității. În timpul dezvoltării, testele pot fi executate prin simpla actualizare a paginii de test într-un browser.

Pentru integrarea continuă (și asigurarea testelor efectuate în toate browserele), voi folosi Selenium pentru a încărca automat testul în fiecare browser și citiți rezultatul. Aceste teste vor fi executate la fiecare verificare la controlul sursei.

De asemenea, o să folosesc JSCoverage pentru a obține analiza de acoperire a codurilor pentru teste. Acest lucru va fi, de asemenea, automatizat cu Selenium.

În prezent sunt în mijlocul stabilirii. Voi actualiza acest răspuns cu detalii mai detaliate odată ce am stabilit configurația.


Instrumente de testare:

0
adăugat

Acesta este motivul principal în care am trecut la Google Web Toolkit ... Dezvolt și testez în Java și am o așteptare rezonabilă că JavaScript compilat va funcționa corect pe o varietate de browsere. Deoarece TDD este în primul rând o funcție de testare a unităților, cea mai mare parte a proiectului poate fi dezvoltată și testată înainte de compilare și implementare.

Integrarea și testele funcționale verifică dacă codul rezultat funcționează după cum este de așteptat după ce este implementat pe un server de testare.

0
adăugat

Nu am reușit niciodată codul UI TDDed. Cea mai apropiată dintre noi a fost într-adevăr să separăm codul UI cât mai mult posibil de logica aplicației. Acesta este motivul pentru care modelul modelului de vizualizare este util - modelul și controlerul pot fi TDDed fără prea multe probleme și fără prea multă complicație.

Din experiența mea, viziunea a fost întotdeauna lăsată pentru testele noastre de acceptare de către utilizatori (am scris aplicații web și UAT-urile noastre au folosit HttpUnit din Java). Cu toate acestea, la acest nivel este într-adevăr un test de integrare, fără proprietatea test-in-isolation dorită cu TDD. Datorită acestei configurații, a trebuit să scriem mai întâi controalele/modelele/codul nostru de comandă, apoi UI și UAT corespunzătoare. Cu toate acestea, în codul GUI Swing pe care l-am scris în ultima vreme, am scris mai întâi codul GUI cu stubs pentru a explora designul meu de front-end, înainte de a adăuga la controler/model/API. YMMV aici.

Deci, pentru a reitera, singurul sfat pe care pot să-l dau este ceea ce pare să suspectezi deja - separă-ți codul UI de logica ta cât de mult posibil și de a le împărți.

0
adăugat

Am făcut unele TDD cu Javascript în trecut, iar ceea ce trebuia să fac era să fac distincția între testele Unit și integrarea. Seleniul va testa site-ul dvs. global, cu ieșirea de pe server, backspacele sale, apelurile ajax, toate acestea. Dar pentru testarea unitară, nimic din acest lucru nu este important.

Ceea ce doriți este doar interfața cu care veți interacționa și scenariul dvs. Instrumentul pe care îl veți folosi pentru acest lucru este în esență JsUnit , care ia un document HTML, cu unele funcții Javascript pe pagină și le execută în contextul paginii. Deci, ceea ce veți face este să includeți textul Stubped out pe pagina cu funcții. De acolo, puteți testa interacțiunea script-ului cu componentele UI din unitatea izolată a codului HTML, script-ul dvs. și testele.

Acest lucru poate fi un pic confuz, așa că vă permite să vedem dacă putem face un mic test. Permiteți unor TDD să presupună că, după încărcarea unei componente, o listă de elemente este colorată pe baza conținutului LI.

tests.html

<html>
<head>
<script src="jsunit.js"></script>
<script src="mootools.js"></script>
<script src="yourcontrol.js"></script>
</head>
<body>
    
  • red
  • green
   
</body>
<script>
    function testListColor() {
        assertNotEqual( $$("#mockList li")[0].getStyle("background-color", "red") );

        var colorInst = new ColorCtrl( "mockList" );

        assertEqual( $$("#mockList li")[0].getStyle("background-color", "red") );
    }
</script>


</html>

Evident, TDD este un proces în mai multe etape, deci pentru controlul nostru, vom avea nevoie de mai multe exemple.

yourcontrol.js (pasul 1)

function ColorCtrl( id ) {
 /* Fail! */    
}

yourcontrol.js (pasul 2)

function ColorCtrl( id ) {
    $$("#mockList li").forEach(function(item, index) {
        item.setStyle("backgrond-color", item.getText());
    });
    /* Success! */
}

Probabil că puteți vedea punctul de durere aici, trebuie să păstrați codul dvs. HTML martor aici pe pagină, sincronizat cu structura a ceea ce va controla serverul dvs. Dar vă oferă un sistem frumos pentru TDD'ing cu JavaScript.

0
adăugat
JavaScript, România - Moldova
JavaScript, România - Moldova
254 participanți

Comunitatea Română JavaScript: github.com/js-ro Pentru confort, opriți notificările. Parteneri: @node_ro, @php_ro, @python_ro, @seo_ro, @RomaniaGroup, @ai_ro, @Grupuri_IT Offtop: @holywars_ro Joburi: @js_jobs_ro Sponsored with ❤️ by ciupacabra.com

JavaScript jobs România Moldova
JavaScript jobs România Moldova
109 participanți

Pentru confort opriți notificările. Vorbim despre posturi de muncă și freelance, proiecte proprii.