Cam acum două luni @iamntz mi-a plantat în cap idee utilizării TDD. Între timp am citit articole, m-am uitat la tutoriale, am citit (mai pe sărite) 2 cărți legat de TDD.
Totul este roz până când mă apuc efectiv să scriu testele. Pe baza celor câteva teste scrise, am observat că îmi este mai ușor să scriu integration tests decât unit tests.
iar dacă vrei să vezi o aplicație construită de la zero folosind această metodologie (și nu numai), îți recomand să te uiți pe codebase-ul de la Sylius: https://github.com/Sylius/Sylius
o să vezi acolo teste și spec-uri făcute cu Behat, PHPSpec și PHPUnit și o să înțelegi mai bine cum ar trebui făcută o arhitectură care să-ți permită să faci TDD.
nu în ultimul rând, îți recomand să te uiți pe tutorialele celor de la SymfonyCasts. chiar dacă nu e neapărat Laravel, conceptele sunt în mare aceleași.
@IceRidder nu am use case. Pare util așa că în week-end voi creiona unul.
@GabiUdrescu Mulțumesc, știu de meet-upurile Symfony dar nu am ajuns la vreunul. Voi încerca să-mi aranjez programul astfel încât să ajung la cel de miercuri.
Nu integral. Este pentru o versiune mai veche de Laravel, dar cel putin in cazul meu a fost interesant de aflat modalitatea de abordare si mai putin framework-ul pe care se lucreaza.
Cred că mai întâi îți trebuie un domain expert sau mai mulți pentru problema respectivă. Și este de fapt design sau mai bine spun învățare despre domeniul respectiv.
Și de fapt ce anume testăm? Comportamentele de domeniu și apoi restu, asta dacă se dorește pornirea de la domeniu. Astea pot fi exprimate liber sau sub forma de domain events, ceea ce poate conduce spre arhitectură de tipul ports and adapters, sau spre cqrs/es, ideea este că atunci când testăm domeniul respectiv, costul de traducere din domeniu în soluție să tindă spre zero.
Cum abordezi: bottom-up de la domeniu înspre integrare, sau top-down de la integrare spre domeniu. La top-down, poate fi echivalent cu bottom-up dacă în loc de sistem(web/consolă/api) folosești domeniul aplicației care este la fel indiferent de integrare, a se vedea modelling by example. O altă chestie importantă este limbajul folosit, de preferat declarativ și în termenii de domeniu respectiv și nu tehnic și imperativ, și modul în care îl descoperii, de preferat într-un mod vizual, cu stickies notes on the wall, vezi example mapping sau eventstorming. Și după mine, mai este important, pe lângă vizualizarea conceptelor și modul de exprimare, care poate fi într-o formă liberă, fără reguli, sau într-un format impus cu anumite reguli ca într-un joc.