Ceea ce vreau sa spun de practicieni și paradigme? Desigur, modelul arhitectural MVC (modelul de vedere controler), și modelele de cod de organizare. Ca urmare acestea nu sunt trucuri inteligente, vei fi capabil să scrie cod mai bine, ceea ce nu va numai ușor de întreținut, dar au capacitatea de a de testare automată.
Greseala cea mai testere
Nu este un secret faptul că cea mai populara metoda de testare a fost întotdeauna un control banal pe „ochi“. Esența ei este simplu de scandalos - a scris câteva mii de linii de cod, a rezolvat problema și să lanseze creația sa. Pentru a reda, poklikat - la fel ca toate lucrările, puteți completa în luptă Server. Totul este simplu și cu atenția cuvenită pentru dezvoltatori (în mod ideal „tester“ a individului de porecla), vă puteți baza pe corectitudinea cererii.
În practică, totul se întâmplă un pic diferit. Testerul individuală, de regulă, nr. Dezvoltatorul în sine este încercarea de a testa funcționalitatea programului prin efectuarea definit în termenii de secvență de referință. Mai mult cod avansat forja, automatiza testarea de integrare cum ar fi utilizarea lucruri cum ar fi seleniu.
Astfel, programatorul este capabil să detecteze numai cele mai grave erori. Din păcate, „prost“ și „neprevăzute“ acțiuni personalizate, precum și mișcările viclene în logica de afaceri, în 99% din cazuri rămân în spatele scenei.
Prezența individului în fața tester rezolvă problema, de asemenea, parțial și până la o anumită perioadă de timp. Chiar dacă am ignora saperskuyu atenție la detalii, calitatea testelor sale va tinde la zero, cu creșterea cererilor. Aici este un exemplu de practică.
teste de unitate ca un glonț de argint
Salvați nervii și de a crește garanția disponibilității pieselor individuale ale cea mai bună aplicație de testare unitate de ajutor. Dacă nu ați experimentat acest cuvânt teribil, se va explica pe scurt. Testele unitare pot automatiza procesul de testare și se supune încercărilor fiecare caracteristică aplicație.
După finalizarea noilor caracteristici (teste posibile de ortografie și înainte de dezvoltare) dezvoltator scrie un cod special pentru a testa codul lor. Codul de testare nevoie pentru a simula situații diferite și de a reveni valori. De exemplu, am scris o funcție pentru a trunchia spațiile (Decupați). Pentru a testa funcționarea acestuia trebuie să ne pregătim câteva teste care permit să se afirme că:
Putem adăuga, de asemenea, de testare pentru alți parametri de intrare (de exemplu, pentru a înlocui caracterul spațiu o filă). În general, cu atât mai bine vom acoperi testele de cod, și să permită opțiuni negative, este mai probabil ca momentul cel mai important în cap va fi un fir de păr puțin.
În lumea JS, testele sunt descrise, de obicei, prin intermediul unor cadre specifice. Ei au tot ce ai nevoie pentru a descrie testele, iar la instrumentele foarte slabe pentru organizarea progresului rapoartelor de testare.
Teste! = Cod suplimentar
Dezvoltatorii care nu utilizează unități de testare, cum ar fi să susțină că unitate de testare necesită scrierea și suportul pentru cod suplimentar. Se spune că momentul în proiecte reale de multe ori comprimat și scrie cod suplimentar pur și simplu nu este posibil.
Din cauza timpului scurt aș fi de acord, dar pe de o parte a pariului cod suplimentar. Pe de o parte, da, testele necesită cod suplimentar, și, astfel, timpul să-l scrie. Pe de altă parte, codul îndeplinește rolul de airbag-uri în vehicul și întotdeauna plăti cu o creștere a cererilor.
Nu orice cod este testat
De ce spun că trebuie să se gândească la testare înainte de a scrie codul de bază? Deoarece codul pe care trebuia inițial să acopere unități de teste, scrise într-un stil ușor diferit. Nu orice cod poate fi testat. Codul care imbina logica si de prezentare, și chiar și în cazul în care este imposibil să chestii testate în mod corespunzător. Aici întotdeauna am sfătui să rămânem la câteva reguli simple:
QUnit - clasic al genului de la creatorii de jQuery
Pentru a demonstra testul, am creat un proiect simplu cu următoarele struktoroy:
Acum, uita-te la testele de sine. Pentru a efectua inspecții ale codului nostru funcționează biblioteca Qunit.js ne oferă o serie de metode:
În a doua listă, am demonstrat cum să aplice aceste metode în practică. Dacă executați un caz test în așa fel încât toate testele sunt finalizate cu succes (a se vedea. Cifra corespunzătoare). Pentru a vedea diferența dintre un test trecut cu succes și eșuează, am schimbat codul de un pic de aluat. În conformitate cu aluatul folosind strictEqual (), evident, am spus rezultatele greșit (a se vedea. Cifra corespunzătoare).
Listarea 1. Conținutul fișierului index.html
Listarea 2. Test de fișiere și tăiați () funcția
Diferența principală a acestui exemplu de cea anterioară - în locul încercării de înfășurare () se utilizează asyncTest (), prin aceasta spunând că sunt direct interesat de testare este testarea asincron. Data viitoare am alerga așteptare de 500 ml. sec. Pe parcursul acestui timp, myAsyncFunc funcția () va transmite date la serverul de test, și dacă toate nishtyak return true. Aici vine cel mai interesant moment. Atunci când există un apel asyncTest () fir de execuție este oprită, iar la final, este necesar pentru a rula testul singur. Pentru a controla fluxul de executie in QUnit au metode de start () și stop ().
Testarea funcțiilor asincrone folosind biblioteca QUnit efectuate destul de simplu. Ultimul exemplu pe care aș dori să fac afară, este asociată cu scrierea testului de executare mai multe controale asincrone. Principala întrebare care apare la acest lucru în astfel de probleme - cel mai bun loc pentru a începe executarea debitului. Dock Oficial oferte se aplică în aceste cazuri, ceva de genul:
Testul pentru acțiunea personalizată
Listarea 3. intrarile de la tastatura de înregistrare în jurnal
Acum vom încerca să testeze această caracteristică. Primul lucru pentru a testa corpul, avem nevoie să imite intrarile de la tastatura. Cel mai simplu mod de a face acest lucru, folosind biblioteca jQuery. care vă permite să creați un eveniment în câteva linii de cod (a se vedea. Listarea 4).
Listarea 4. Cod de încercare pentru Keylogger
La începutul listării cu aluatul, ma pregatesc un eveniment pentru a imita o apăsare de tastă - «KeyDown». Suntem interesați de apăsarea tastei Tab (cod 9). Apoi, folosind metoda de declanșare () am trimite eveniment fierte, atunci puteți începe testarea. În primul rând verificați imaginea de ansamblu - a fost a fost apăsată o tastă, apoi codul.
teste sub acoperire DOM
Phantom.JS - rula teste de pe consola
Scrie teste folosind Qunit.js Biblioteca este convenabil și ușor, dar mai devreme sau mai târziu va vizita dorința de a automatiza cumva testarea de pornire și a rezultatelor de colectare. De exemplu, am pentru acest caz, există o mașină virtuală separată în DigitalOcean. de control pe care le pot folosi doar consola.
Este suficient rezolvă elegant, acest proiect problemă phantom.js. Acest lucru nu este doar un alt cadru pentru scris unitate de teste. și o versiune completă consolă a motorului WebKit. Pentru a pune pur și simplu, acest lucru este aplicația emulează browser-ul. Cu ajutorul phantom.js într-adevăr nu ușor pentru a automatiza verificarea testului, dar, de asemenea, rezolva multe probleme, cu care se confruntă mai devreme sau mai târziu de dezvoltator: obține pagini rendinga de rezultate într-un fișier (png, jpg), ca un monitor de rețea (viteza de download, performanța generală și așa mai departe. d.), emularea acțiunilor efectuate de utilizator, etc. Nu recomand să fie leneș și citiți documentația oficială privind acest proiect, asigurați-vă că pentru a găsi ceva interesant pentru ei înșiși.
Să încercăm să se cunoască phantom.js în practică. Pentru a trece prin teste phantom.js preparate în secțiunea anterioară și a obține rezultatele în consola avem nevoie de un script-încărcător de construcții - run-qunit.js. Deschideți consola (am de lucru pe Windows, așa că folosesc cmd) și umple comanda în formatul:
În cazul meu, comanda run este pornit după cum urmează:
Toate testele au trecut
Testele de cod Coperta este absolut necesar, și indiferent de amploarea cererii pe care o creați. Încă o dată să vă amintesc chiar și cele mai mici programe sunt transformate în monștri greoi, care trebuie să fie menținute și funcționalitate dopilivat. Bune teste de acoperire cod - succesul și de calitate. Da, aici atât de repede începe scrierea potrivit pentru codul automat de testare nu este ușor, dar crede-ma, toate aceste chinuri vor fi compensate în viitor. Pe aceasta am pentru azi, noroc!
Atunci când testele nu au timp
În cazul în care nu există nici o nici un sens să mâzgălească teste pentru funcții simple (pentru a lua același asieta () din exemplele din acest articol), este mai bine să se concentreze pe secțiunile cele mai critice de cod. Aderă la aceleași reguli ar trebui să fie în scris, codul de multe ori variabila. Termenii de referință a proiectului de viață variază de multe ori, iar unele funcții trebuie să fie actualizate în mod constant. Astfel de modificări pot duce la momente neplăcute - cod modificat funcționează bine cu noile date și vechi organic nu se digera. Asta nu este de a prinde aici Feil, o funcție similară este mai bine pentru a acoperi testele. Amintiți-vă o regulă simplă - nu au timp pentru a acoperi toate testului de cod, se taie cea mai importantă parte din ea.
Reguli de teste bune
phantom.js probleme în Windows
Dacă vă confruntați cu o problemă similară și intenționează să utilizeze phantom.js pe Windows, pentru a primi apoi gata să facă următorul hack. Deschideți Panoul de control Nvidia. Găsiți „Opțiuni 3D» element din copac. Pe partea dreaptă opțiunea „adaptor grafic preferate“ ar trebui să apară. În mod implicit, valoarea sa este setată la „Auto“. Trebuie să-l schimbe la „procesor de înaltă performanță Nvidia“ sau „hardware-ul grafic integrat.“ După acest truc simplu phantom.js a început să se comporte ascultător.
Ce să citească
