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ţie
Documentare
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.
de Dan Sabadis
de Petra Ivașcu
de Emilia Toma
