ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 142
Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 63
Abonament PDF

Testare și BDD. Interviu cu Thomas Sundberg

Ovidiu Mățan
Fondator @ Today Software Magazine



INTERVIU

Thomas, suntem foarte bucuroși că participi ca speaker la IT Days 2017. Te descrii drept un "programator infectat de teste". Cum definești acest lucru?

Thomas Sundber: Este vorba de a fi acel programator care nu se simte bine când nu își modelează codul după teste. Un test poate avea multe forme și faţete, dar rămâne mereu executabil. Pot rula o mică bucată din sistem și să primesc feedback rapid dacă am stricat ceva. Acest lucru mă scapă zilnic de foarte multe probleme.

Mereu încerc să fac programare ghidată de teste (test-driven development) și fac asta de 15+ ani.

Test infected developer @ Think Code AB

Unul din subiectele tale preferate este programarea ghidată de comportament (Behavior Driven Development). Cum poate o întreagă echipă să folosească acest stil de programare?

Thomas Sundber: Behaviour-Driven Development (programarea ghidată de comportament) sau BDD, a apărut când Dan North a încercat să explice Test-Driven Development (programarea ghidată de teste) sau TDD. Dan a descoperit că dacă nu menţionezi cuvântul 'test' într-o conversaţie, unii programatori te vor asculta. Dacă vei introduce cuvântul 'test', ei nu te vor asculta deoarece testarea aparţine testerilor, iar ei sunt programatori.

BDD a evoluat de când Dan a folosit termenul pentru a preda TDD, un proces unde aveţi conversaţii despre ceea ce ar trebui să implementaţi. Această conversaţie, de multe ori intitulată "three amigos" ("cei trei prieteni"), este apoi documentată pentru a putea fi implementată ușor. Executarea exemplelor este apoi folosită pentru a duce implementarea mai departe.

Există trei pași de urmat:

Conversaţia este elementul în care toată echipa ar trebui implicată. Aici se discută user story (scenariul pentru utilizator) și se caută exemple concrete care să descrie acest scenariu. Este ușor pentru un product owner să considere un scenariu clar și lipsit de ambiguitate. Se pare, însă, că realitatea este exact opusă. Scenariile sunt deseori vagi și nu foarte clar înţelese de toată lumea. Acest lucru este uneori evident când încercaţi să găsiţi exemple concrete care să descrie scenariul fidel și detaliat. Este normal ca product ownerul să nu poată răspunde la toate întrebările.

Dacă toată echipa e implicată în identificarea de exemple concrete, greșelile pot fi evitate chiar de la începutul procesului de dezvoltare. Dacă sunt întrebări la care product ownerul nu poate răspunde, atunci acesta este un semn că e nevoie de mai multă muncă pentru a înţelege care este scopul scenariului.

Documentarea exemplelor se face apoi de un tester sau un programator, iar apoi documentele sunt revizuite de product owner pentru a putea identifica greșelile.

Ultimul pas ţine de implementarea comportamentului. Acest lucru este realizat de programatori, iar exemplele concrete și executabile se folosesc pentru a ghida implementarea.

Când execuţia comportamentului documentat trece fără probleme, dezvoltarea unei anume funcţionalităţi este gata. Pare ușor, dar implică multă muncă care poate aduce rezultate dar și distracţie!

Selenium este un tool popular pentru automatizare paginilor aplicaţiilor web. Ce sfaturi le dai celor care folosesc Selenium?

Thomas Sundber: Primul sfat este de a folosi Selenium cât mai puţin posibil. De ce?

Selenium este lent și predispus la erori, deoarece partea UI este bucata care se schimbă cel mai mult și mai frecvent în aplicaţii.

Asta nu înseamnă că este interzis să folosiţi Selenium dacă doriţi. Poate fi folosit, dar știu și că o bună parte din testare se poate face cu UI, iar mulţi testeri și programatori nu realizează asta.

Am postat pe blog un articol numit "Where should you use Behaviour Driven Development, BDD?" ("Unde ar trebui să folosesc Behaviour Driven Development, BDD?"),

n-development-bdd unde menţionez piramida de testare Agile (Agile Testing Pyramid). Pe scurt, trebuie să evitaţi prea multe teste complete (end-to-end). Selenium este un tool adesea folosit pentru teste complete, deci are anumite deficienţe.

Selenium este un tool bun care nu ar trebui folosit în exces.

Al doilea meu sfat este separarea navigării de testare.

Ce vreau să spun cu asta? Un test nu ar trebui să fie influenţat de navigarea pe o pagină web. Un test ar trebui să se preocupe doar cu ceea ce pagina web poate să furnizeze la nivel de funcţionalitate. Testul ar trebui să verifice dacă anumite operaţii sunt posibile.

Cum rămâne cu navigarea? Scoateţi navigarea din test și puneţi-o pe seama unui adjuvant care nu se ocupă cu testarea, dar care este interesat doar de navigare și de interacţiunea cu pagina web. Acest lucru este implementat sub formă de Page Objects. Am postat pe blog un articol numit "Separation of concern when using Selenium" ("Separarea grijilor când folosim Selenium")

Page Objects sunt un mod uzual de obţinere a acestei separări, dar motivul pentru care sunt bune nu este mereu înţeles. În ceea ce mă privește, Page Objects în sine nu sunt interesante. Este interesant să avem un test care spune clar ce testează fără a ascunde acest lucru în spatele a foarte mult cod de navigare.

Al treilea meu sfat ţine de dezvoltarea și mentenanţa codului testat. Acesta trebuie menţinut. Nu neglijaţi mentenanţa testelor. Dacă o faceţi, veţi ajunge într-o situaţie în care testele nu vă mai ajută, iar acestea ar putea fi chiar șterse.

Codul de test este cel puţin la fel de important ca cel de producţie, deoarece îţi permite să te miști rapid când știi că nu ai stricat nimic făcând o modificare. Codul de test și codul de producţie trebuie scrise de aceeași persoană ca să evolueze în paralel.

Cu ce așteptări să vină participanţii la IT Days la prezentarea ta?

Thomas Sundber: Voi face tot posibilul să explic că o foarte mare parte din testare poate și ar trebui să se facă utilizând unit tests în loc de end-to-end tests sau integrated tests. Prin termenul integrated înţeleg testarea unor bucăţi mari de cod simultan. Nu mă refer la testarea integrării cu alte dispozitive externe.

De ce este atât de important? Este important, deoarece puteţi să vă asiguraţi că toate cazurile sunt acoperite cu un singur test ce se aplică unei bucăţi mari de cod. Dacă încercaţi acest lucru, veţi vedea că numărul cazurilor de luat în calcul este prea mare. Nu se poate face, iar dacă s-ar putea, ar fi prea lent.

Vrem să ne asigurăm că sistemul funcţionează bine și nu vrem să ne trezească un client nervos din somn noaptea ca să ne vorbească de un sistem care nu merge, dar care a costat mulţi bani.

Vreau să dorm bine noaptea și să nu muncesc suplimentar pentru a realiza acest lucru. Pentru aceasta am nevoie de o plasă bună de siguranţă care să mă salveze pe mine și pe colegi când facem greșeli.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects

INTERVIURI VIDEO