Episodi 003: Test-Driven Development amb Dave Farley

Introducció

[Descripció generada automàticament. Revisa i personalitza segons calgui.]

Hola a tothom, benvinguts a la nostra dita d’avui

Transcripció completa

Hola a tothom, benvinguts a la nostra dita d’avui. Sí. I parlarem de desenvolupament test-driven. TDD. TDD, sí. T’has enviat un munt d’insights de la YouTube de Dave Farley. Sí. I he de dir que estic bastant curiós d’aquest tema. Sí. Sembla que TDD sigui una d’aquestes coses que la gent o realment estimen o completament evoquen. Per què hi ha una reacció tan forta d’eixos? És fascinant, no? I és una cosa que la gent té opinions molt fortes sobre. I crec que la cosa que està passant allà és que la gent sovint no entén quina és la idea corell d’TDD. Tindrem una mirada en detall a la perspectiva de Dave Farley per entendre per què ho és. Sí. Sembla que moltes vegades la gent pensi que TDD és només sobre testar. Sí. Però Dave Farley realment enfatitza que és més que això. Sí, absolutament. La manera com Dave Farley la descriu és que TDD és una tècnica de designació. És sobre utilitzar testes com a tool per ajudar-te a designar la teva software. Usa aquesta bonica anàlisi d’un carpenter que es diu TDD. Usa una tècnica de T. No és sobre restricció de la creativitat del carpenter, és sobre ajudar-los a fer que les coses que estan construint siguin square i veres. És un punt molt bé. No és sobre limitar-te, és sobre ajudar-te a crear una cosa que sigui ben estructurada. És clar. I és aquí on ve el famós cicle de refactor de la red-verda. Ok, he sentit això, però, a ser honest, no estic gaire segur que ho entendi. És, en realitat, gairebé straightforward. La manera com funciona és que escrius un test que descriu què vols que el teu codi faci. I, és clar, perquè no has escrit el codi encara, el test farà malament, i és la fase roja. Aleshores, escrius prou codi per fer que el test passi. Ok. Aquesta és la fase verd. I, a la fi, refactores, que vol dir millorar la estructura i la llegibilitat del codi sense canviar el seu comportament. Així és com un cicle de feedback constant on sempre refines i millores. Sí. Sembla que això podria ser una manera molt efectiva de construir sistemes complexos. Però, ¿aquest aproach ajuda a evitar aquelles bases de codi que som tots veus? Absolutament. Realment ho fa. Una de les maneres en què ho fa és que actua com un tipus d’escenari d’abans per a les faltes de design. Així que, si trobes un test difícil de escriure, és sovint un signo que el teu design és too complex o too tightly coupled. ¿Pots explicar què vol dir coupling en aquest context? Jo crec que alguns dels nostres espectadors no estarien familiaritzats amb això. Llavors, coupling i software design refereixen a com molt de diferents parts del teu codi depenen d’un altre. Ok. High coupling vol dir que canvis en una part del teu codi són possibles de trencar coses en altres parts. I això fa que el teu codi sigui difícil de mantenir i canviar. D’acord. TDD et encoratja a pensar sobre aquestes dependències des del principi i a designar el teu codi en una manera més mòdula i lússament coupleda. D’acord. Això fa sens. Així que TDD et ajuda a trobar aquests problemes potencials a l’abans. Exactament. I en dona un gran exemple d’això. En parla d’encontrar un test que requereix un servei d’encontrar Jenkins per a que es reuneixi només per a mirar per host local en una URL. Uau, això sembla una mica extrem. És un signo clar que alguna cosa no està bé amb el design. Sí, puc veure com una situació com aquesta pot ser ràpidament un malament per gestionar. És com intentar construir una casa on cada lloc és connectat a cada altra lloc amb no hi hagi separació clara. Seria increïble de fer canvis o fixar problemes sense afectar tot el que altres. I TDD et ajuda a evitar aquest tipus d’arquitectura messa en el teu codi. Així que com això s’acorda amb la idea de TDD com a design? Bé, si penses en aquests 5 qualitats de codi ben designat que el menciona, modularitat, cohesió, separació de preocupacions, abstracció i poca combinació, aquestes són totes qualitats que es van emergir naturalment quan practiques TDD. Perquè estàs constantment pensant sobre com escriure codi testable, ets forçat a fer choices de design que suporten aquestes qualitats. Entenc. Així que no és com si TDD fos una activitat separada de la designació. Sí. És actualment basat en l’entorn de la desenvolupament. És clar. I aquesta és una de les raons per les quals pot ser tan poderosa. No és només sobre adicionar testos després de la factura, és sobre utilitzar testos com a tool per guanyar i shapear el design de la teva software des del primer moment. Això ja m’està fent resoldre com aprofito la desenvolupament. Em sembla que TDD podria ser molt valible per a construir una software més robusta i mantenible. Però què tal l’argument que TDD tancarà la desenvolupament? M’imagino que escriure tots aquests tests a l’abast podria demanar molt d’extra temps. Aquesta és una preocupació molt común i definitivament en parlarem més. Però primer, fem una visió més proactiva a l’idea de desenvolupament o BDD, que es basa en els principis de TDD. Ok, doncs BDD és relacionat amb PDD. Sí. Pots pensar-te-ho com una evolució de TDD on el focus s’escapa encara més cap al comportament de la software des del punt de vista dels users. Interessant. Aleshores, com funciona BDD en el procés? Què fa que sigui diferent de escriure tests de unites regulars? BDD és tot sobre fer aquests tests més legibles per a la humanitat i enfocats en els resultats que l’user s’enviarà. Aleshores, en comptes de escriure un test que diu verifia que el metàl·lit X retorna la valoració Y, escriuries un test que diu una cosa com quan un usuari adició un item a la seva carteta, la carteta total hauria d’update correctament. Això fa molt de sens. És sobre framear aquests tests en termes de històries d’users i escenaris reals. Exacte. I això té uns beneficis molt significats. Sí. Un dels avantatges és que els tests de BDD són molt més fàcils per a la gent no-tècnica d’entendre. D’acord. Aleshores, si treballes en un team amb managers de productes o designers o fins i tot clients, utilitzant una llengua més humana legible per als teus tests pot millorar molt més la comunicació i la col·laboració. D’acord. Aleshores, en comptes de ser un document tècnic que només els desenvolupadors poden decipherar, els tests es tornen una comprensió de com el software ha de comportar. Exacte. Dave Farley parla d’aquesta idea de tornar unes visites en concrets exemples. Oh. Aleshores, comencem per entendre el que l’user vol aconseguir. D’acord. Després defineix escenaris específics que il·lustren aquests objectius. I, finalment, tornes aquests escenaris en especificacions executables, que són els tests de BDD. Són coses que poden ser de manera particular útil quan parles d’interaccions d’users o de workflows. Absolutament. I també et permet evitar escriure testos molt complexos i brits. D’acord. Recordeu com parlàvem de la cúpula? Sí. BDD t’encoratja a focusar en els resultats que importen a l’user en comptes de les detalles internes d’implementació del teu codi. D’acord. I això porta a testar testos que són més robustos i menys probablement de trencar quan fas canvis al codi d’enllaç. Això fa molta sensació. Sí. Focant-se en el què en comptes de com crees una base més estable per als testos. D’acord. És com construir una casa en terra solidària en comptes de en sandalia. Sí. Els testos es tornen més rellevants i menys prone a positives falses o negatives. Això m’agrada una nova apreciació per la pensió que va enllà de escriure bons testos. Sí. És definitivament més que només adicionar unes assertions aquí i allà. D’acord. Testos ben escrit, especialment testos de BDD, poden servir com a documentació valora. D’acord. I ajudar a assegurar que tothom involucrat en el projecte és al mateix pagament. Fins ara, hem parlat de testar la logica de la darrera. Però què tal amb la interface d’usuar? Com aplices aquests principis a una cosa tan dinàmica i complexa com una UI? És una bona pregunta. I és un àrea en què molts desenvolupadors s’estrenen. Sí. Però la perspectiva d’en Dave Farley és molt interessant. Emphasiza que és la nostra responsabilitat com a desenvolupadors de fer que la nostra UI sigui testable. No és sobre la culpa de la complexitat inherent de la desenvolupació de la UI. És sobre que la nostra responsabilitat és fer choices de design conscients que simplifiquen la testa. D’acord. Però com fem això? Quins consells pràctics? Bé, el Dave suggeria unes estratègies clau. Una és l’abstracció. Aleshores, en comptes de testar la UI directament, podem crear abstractions que representen elements de la UI en les seves interaccions. Aleshores, en comptes de escriure un test que clica un botó específic a la pantalla, interactaríem amb una representació abstracta d’aquest botó en el nostre test. Exactament. I això ens permet testar la lògica darrere de la UI sense ser aturats a detalls visuals específics que pot canviar. Això sembla molt més robust i menys probable que es trenqui si el design de la UI és tweakat. Exactament. I la següent estratègia és fer servir una combinació de testos de unit i testos d’integració. D’acord. Així podem fer servir testos de unit per testar els components de la UI en isolació. D’acord. I després podem fer servir testos d’integració per verificar que aquests components funcionen correctament en el context de l’applicació overall. És com fer que cada part d’un motiu de la carrer funcioni correctament i després testar que l’entorn de l’enginy es reuneix de manera fàcil quan assemblat. Perfecte anàlisi. I això porta a un altre punt important que ell afilata, que és l’importància de controlar variables quan escriu testos. Controlar variables, sembla una mica com un experiment de ciència. D’alguna manera, ho és. Estem intentant crear testos rellíps i predictables. D’acord. I per fer això hem d’isolar les parts del nostre codi que estem testant i assegurar que els factors externs no influen els resultats. D’acord. Estic començant a veure com això pot ser trígic. Però quines són algunes maneres de controlar aquests variables en la pràctica? Com gestiones coses com databases o sistemes de fàcil o connexions de neteja en els teus testos? Una tècnica molt común és utilitzar mocs o fakes. Pensa-te-hi com els dubles de la fàcula en un filme. Estan en per la realitat, permetent-te simular behaviors específics i respostes en un ambient controlat. Aleshores, en comptes de connectar a un real database en el teu test, utilitzaries un mock database que retorna dades predefinides. Precisament. I això et dona molt més control en l’ambient de testar i et permet evitar resultats impredictibles que podrien ser causats per factors externs. Sembla una manera molt poderosa d’assistir que els teus tests siguin focats i rellevants. És. I controlant aquests variables també adones-te de més confiança quan refactores el teu codi. D’acord. Deixem-nos refactorar. Ho hem parlat una mica abans, però podries explicar en més detall com es fa per millorar el teu codi sense canviar el seu comportament extern. És com tancar la teva casa i rearranyar la teva furnitura per fer-la més funcional i estètica sense canviar el seu propi de la teva casa. Així no adones-te de noves feinades o fixar bugs, només fent el codi existent menjar i més fàcil de treballar. Exactament. I això és on tenir una suïtia de comprensió de tests, particularment els creats a través de TDD, torna molt valent. D’acord. Perquè els teus tests són molt valents. I és com per verificar que la funcionalitat del teu codi funciona correctament. Pots fer canvis a la estructura intern sense preocupar de trencar coses. És com tenir una neta de seguretat perquè pots experimentar i fer millorar sense la risca de caure en la teva cara. És un bon motiu per dir-ho. I refactorar no és només sobre estètica o fer que el codi sembli bonic. D’acord. Té un impacte profund en la salut i la sostenibilitat de la teva base de codi. D’acord. Pot fer a la modularitat millor, i a la sostenibilitat de la teva base de codi. Així que no és només un bon motiu. És una part crucial de la construcció de la software que pot evolucionar i adaptar a l’hora. Absolutament. I fins i tot sugereix que refactorar pot fer millor design. Espera, com és possible? Jo pensava que refactorar era només sobre tancar els codis existents. Ho pot ser, però també pot ser un tool poderós per descobrir les faltes de design i explorar solucions alternatives. Oh. Llavors, ell descriu la situació en què treballava en un joc de batalla. Ok. I, en el procés de refactorar, va adonar-se que va mancar un concepte clau, les regles del joc. Interessant. Per introduir aquest concepte i reestructurar el seu codi d’acord, va poder simplificar el design i fer-lo molt més elegant. Això és fascinant. Així que no és només sobre fer el codi més bonic. És sobre desenvolupar més d’insights i millorar el design a un nivell fundamental. Exacte. I aquí és on la natura iterativa de TDD es mostra. Constant la circulació d’aquest codi de factor, crees oportunitats per aprendre, refinar i evolucionar el teu design en el temps. Això és definitivament canviant com penso sobre TDD. No és només sobre escriure testos. És sobre aprendre una nova manera de pensar sobre el desenvolupament de software. I aquest canvi en la mentalitat és el que últimament fa a la creació de softwares de qualitat de alta qualitat que poden mantenir-se. Sistemes que són robustes, adaptables i poden superar el test de temps. Em sembla que sóc el cor de la superfície de què TDD és tot sobre. Hi ha sempre més a aprendre i una de les coses que m’ha impactat sobre aquestes sources és l’emphasis en l’element humà de la desenvolupament de software. És fàcil que es perdi en els detalls tècnics però a l’endemà són les persones que estan construint coses per a altres persones. Aquest és un punt molt crític i Dave Farley realment enfonsa l’importància de la comunicació i la col·laboració i fer que tothom entengui què està passant. I sembla que veu el test com una part clara d’aquesta apropiació d’acord. No és només provar que el codi és correcte és provar una manera de identificar quan les coses són malament. Sí. Ell té aquesta gran idea. Un test de solucions és més valuable que milions de testos passats. Pensa-ho com una alarma de fred. No és allà per dir-te que tot està bé. És allà per alertar-te quan hi ha un problema que necessita la teva atenció. És una anàlisi molt bona. Canvia com pensem els tests en comptes de veure-los com una pressió. Comencem a veure-los com una feedback valida que et permet agafar problemes abans. I aquesta anàlisi no és només per a l’individual desenvolupador. Recordeu com discutíem el desenvolupament i el seu èmfasi en les històries i les especificacions? És tot per crear una comprensió de què el software ha de fer. No només entre desenvolupadors sinó també amb productes owners, stakeholders i fins i tot els usadors els mateixos. És com crear una rota que tothom pot seguir assegurant que tots estigueu la mateixa cosa de la mateixa manera. Exacte. Quan tothom està a la mateixa pàgina, ets molt més probable de construir software que realment s’aconsegueix els usadors. D’acord. Així que hem cobert molt sobre com TDD pot millorar el design de la qualitat de la còrrega i la col·laboració. Però hi ha encara aquesta una gran qüestió que s’està afegint. ¿TDD actualment s’aclou el desenvolupament? ¿És valent l’extra temps de la còrrega? És com l’anterior dient que mesura dues cotes una vegada. Exacte. En prenent el temps de pensar al teu design, escriure els tests i refacturar el codi, és essencialment construir una molt forta fundació per la software. I vol dir que ets menys probable de trobar aquests bugs bugs i flaws que poden menjar hores, dies o fins de debugging time later on. Plus, haven’t we all experienced that moment of dread when you have to make changes to a large untested codebase. Yeah. You never know what you might break. Right. But with a good suite of tests you can refactor and make changes with much more confidence knowing that your tests will catch any unintended consequences. So TDD isn’t about slowing down. It’s about working smarter not harder. Precisely. And here’s another really interesting point from Dave Farley. He actually argues that TDD can enhance job security for developers not threaten it. Really? I’ve heard the opposite that some developers fear TDD because it makes their code easier for others to understand and potentially replace. Yeah, I can see why some people might think that. But he makes a compelling case for the opposite viewpoint. By saying that it is a really powerful message. It suggests that TDD is not just a technical practice, it’s a cultural shift that can lead to better software and a more fulfilling work environment. Absolutely. It’s about! Yeah! It’s about building software that can stand the test of time. It’s not just about writing code, it’s about crafting well-designed, robust, and maintainable systems. Keep diving deep, keep challenging yourself, and keep building amazing things.

Fonts

Actualitza aquesta secció amb les fonts reals utilitzades per generar el contingut.

Important: Aquest episodi ha estat generat amb intel·ligència artificial basant-se en fonts públiques. La transcripció s’ha generat automàticament amb OpenAI Whisper. Consulta sempre les fonts originals per obtenir la informació completa.