TDD by Example

Les meves notes de la lectura de Test-Driven Development: By Example de Kent Beck. El llibre cobreix tres grans àrees: un exemple de sistema de diners multi-moneda, construir xUnit des de zero, i un catàleg complet de patrons TDD. Les pàgines originals es troben al final.

Què és TDD?

Test-Driven Development és una tècnica de desenvolupament on escrius els tests automàtics abans que el codi que els fa passar.

Els beneficis principals:

Ritme de desenvolupament predictible — sempre saps en què estàs treballant
Els tests actuen com a especificació del comportament del codi
Es fa bé d’escriure — la barra verda et dona feedback constant

El Mantra: Vermell → Verd → Refactor

Vermell — escriu un test que falli (ni tan sols ha de compilar)
Verd — fes el canvi mínim necessari per fer-lo passar
Refactor — elimina la duplicació sense fer fallar el test

Què resol

Millor QA: la densitat de defectes cau perquè els problemes emergeixen immediatament
Millor comunicació en equip: sense sorpreses desagradables entre developers
Confiança: els nous developers tenen una xarxa de seguretat sobre la qual construir

L’objectiu

Escriure codi que funcioni.

Part I: L’Exemple del Diner

La primera part del llibre treballa un sistema de diners multi-moneda des de zero, guiat completament per tests. L’objectiu és aprendre a escriure tests primer i fer créixer el disseny de forma orgànica.

Capítol 1 — Diners Multi-moneda

El problema de partida:

Acció	Accions	Preu	Total
IBM	1000	25	$25,000
GE	400	100	$40,000
Total			$65,000

El repte arriba quan els preus estan en monedes diferents. Necessites un mecanisme de conversió.

La llista TODO completa ni compila al principi — i aquest és el punt. L’objectiu és fer passar un test a la vegada sense tocar la implementació més del necessari.

La idea central del capítol 1: existeix una dependència real entre test i implementació. La llista TODO la revela immediatament.

Capítols 2–6 — Mecàniques bàsiques

Capítol 2 — Objectes degenerats

Els efectes secundaris apareixen quan comparteixes variables entre tests que parteixen de suposicions diferents. La solució: fer les variables locals per test per aïllar els efectes. Usa fakes i implementacions òbvies, llavors refactoritza en petits passos.

Capítol 3 — Igualtat per a tots

Els Value Objects eliminen la necessitat de preocupar-se pels problemes d’aliasing — són iguals per valor, no per referència. Triangulació: usa 2 o més exemples concrets per generar una implementació més general. Per exemple, testar F(3.0) i F(3.1) et força a escriure el cas general.

Capítol 4 — Privacitat

Troba l’equilibri: fer els camps privats al codi de producció és important, però el codi de test que comprova estat privat revela dependències reals. Deixa que els tests decideixin què roman públic.

Capítol 5 — Sent honestos

Quan una classe que necessita ser testada té dependències, no crees una abstracció immediatament. Duplica la classe i el test. Després abstreu les parts necessàries un cop la forma és clara.

Capítol 6 — Igualtat per a tots, redux

La duplicació es resol amb abstracció — però no et fiïs cegament de la classe abstracta fins que el compilador i els tests ho confirmin. Continua abstenint i eliminant duplicats mentre mantens els tests en verd. Si el disseny és bo i els tests passen, para. Si alguna cosa sembla malament, espera fins que puguis obrir la barra verda de nou.

Capítols 7–11 — Refinant el disseny

Capítol 7 — Pomes i taronges

Comparar objectes de tipus diferents retornarà un null. Testar el comportament fallit explícitament és una forma vàlida de documentació — de vegades el test és l’especificació.

Capítol 8 — Creant objectes

Abstracció oberta: les classes poden fer petits canvis i eliminar assertions perquè la classe arrel realment gestiona la manipulació. Deixa que la jerarquia faci la feina.

Capítol 9 — Els temps en què vivim

La perspectiva del llibre aquí: “No et recomano que donis aquells passos petits. El que et recomano és ignorar el zero (i ser capaç de prendre’l). Si aquells passos són massa grans, fes-los més petits. Si necessites passos més petits, estaràs prou a prop. No hi ha mida de pas correcta.”

La lliçó: la mida del pas s’adapta a la teva confiança. No la prescriguis.

Capítol 10 — Temps interessants

Pots crear mètodes d’ajuda a la implementació que no necessàriament es testin directament. No tot necessita un test — algunes coses existeixen per donar suport al disseny.

Capítol 11 — L’arrel de tots els mals

A mesura que continues escrivint tests i abstrayent, t’adonaràs que ja no necessites les subclasses. L’abstracció elimina la necessitat de les especialitzacions concretes.

Capítols 12–16 — Construint el sistema d’expressions

Capítol 12 — Suma, finalment

Afegir un diccionari (banc d’expressions) permet abstraure la reducció. Un cop l’introdueixes, el problema de l’expressió fallida reapareix — però ara d’una forma més controlada.

Capítol 13 — Fes-ho

L’enfocament del llibre: el primer pas és fer-ho compilar. Estàs trencant l’expressió en la classe peça a peça.

Disciplina clau: mantingues el test honest. No escriguis tests que siguin descartables. El test ha d’estar tan a prop d’una assertion real com sigui possible.

Tests clau per escriure:

testSum
testSumTwoOrMoreNumbers

El codi itera i creix. Per què reduir-lo abans d’entendre’l? Per què perdre’l?

Capítol 14 — Canvi

Pots escriure codi sense tests en el context d’innovació/exploració. Però cal portar-lo sota cobertura de tests abans d’enviar-lo.

Capítol 15 — Monedes mixtes

Quan tens múltiples marques idèntiques a través de tests diferents, extreu un mètode general forEach que cobreixi el refactoring tant per a la classe de test com per a la implementació. Un cop totes les classes i la implementació estan fetes, escriu un test general que asserti els valors privats. Si el test és massa gran, divideix-lo en uns de més petits.

Capítol 16 — Abstracció, finalment

Acabaràs amb aproximadament el mateix nombre de línies als tests i a la implementació. No tinguis por d’afegir codi adjacent que sembli útil — deixa-ho fins al final. El test et dona l’oportunitat de corregir.

Capítol 17 — Retrospectiva del Diner

TDD apesta per a la reflexió — però no és l’ús més efectiu per a ella. En sistemes grans, les parts que toques haurien de ser sòlides com una roca per poder fer tots els canvis sense risc. Això és el pensament SOLID aplicat al disseny de tests.

A mesura que un sistema creix pot tornar-se lleig sense informació sobre el que passa al codi antic.

Mètriques d’auditoria de codi (executades després que tots els tests estiguessin en verd):

Mètrica	Test	Implementació
Núm. classes	1	5
Núm. funcions	15	22
Núm. línies	89	91
Complexitat ciclomàtica	2	2.04
Funcions simples	6	4

Aquestes et diuen sobre la qualitat i el que s’hauria de revisar.

Tres tipus de cobertura per conèixer:

Cobertura de sentències: comprova cada element (simple). Fins que no pots pensar en més tests.
Inserció de defectes: canvia el significat d’una línia de codi — el test hauria de trencar-se.
Simplificació: crea un conjunt fix de tests i simplifica la lògica del programa.

No esperis que TDD substitueixi altres tipus de testing: rendiment, estrès, accessibilitat.

Part II: L’Exemple xUnit

La segona part construeix un framework de testing des de zero (en Python al llibre). L’objectiu és entendre les interioritats de xUnit construint-ne un.

Capítol 18 — Primers passos cap a xUnit

Construïm el nostre propi framework de testing. L’enfocament: escriu el test primer, fins i tot si no compila. Llavors abstreu: agafa una classe que funciona sobre una instància i generalitza-la substituint constants per variables.

Capítol 19 — Posa la taula

Cada test té 3 parts (el patró AAA):

Arrange — crea alguns objectes (possiblement mocks)
Act — simula’ls / crida el mètode sota test
Assert — comprova els resultats

Ves amb compte amb els efectes secundaris entre Arrange i la resta. Cada objecte creat per a cada test no hauria de tenir cap interconnexió amb altres del mateix test. La solució: un mètode setUp que s’executi abans de cada test amb un estat net.

Recorda: 1, 2, n… — quan tens un test, fes-lo passar. Quan tens dos, busca un patró. Quan tens n, generalitza.

Capítol 20 — Netejant després

Quan un test alloca recursos externs, ha d’alliberar-los abans d’acabar per mantenir els tests independents. Això és tearDown. Fer registres basant-se en aquest patró és habitual.

Capítol 21 — Comptant

Una bona pràctica: usa tearDown després de cada test xUnit. No només per evitar efectes secundaris, sinó també per capturar excepcions que poden ocórrer durant l’execució del test. Usar-ho crea un “punt de control” per a cada test.

Capítol 22 — Tractant amb fallades

La majoria de biblioteques de testing et donen totes les anotacions per escriure tests sense preocupar-te per les excepcions gestionades en un altre lloc. Això és per disseny — el framework les absorbeix.

Capítol 23 — Com de bé és Suite

La duplicació composta no és una cosa dolenta si tens la motivació — és part del patró de disseny de testing. Els tests han de tenir la capacitat de ser compostos i executats conjuntament.

Capítol 24 — Patrons xUnit

Assertion — com comprobes que els tests han funcionat correctament?
Escriu expressions booleanes que assertin automàticament si el codi ha funcionat. Les assertions han de ser booleanes, declarades pel codi, han de ser específiques, i escrites usant el protocol públic.

Fixture — com crees objectes comuns necessitats per diversos tests?
Converteix les variables locals del test en variables d’instància. Sobreescriu setUp i inicialitza aquelles variables. L’objectiu principal és eliminar duplicació — però en aquest cas, la duplicació pot ser bona per tota la “documentació” que proporciona un sol test.

Què triar? Prefereixo el primer (variables locals explícites per test) — és més llegible.

Retrospectiva xUnit

Algunes coses d’implementar el teu propi framework de testing:

Els detalls de la implementació no són tan importants com el cas de test
L’objectiu és escriure tests que siguin aïllats i es puguin controlar
Estaràs en camí de desenvolupar test-first

Per què construir el teu propi framework?

Mestratge: control complet sobre un framework amb comprensió total de la seva implementació
Exploració: en aprendre un nou llenguatge de programació, és una excel·lent manera d’explorar-lo dia a dia

Part III: Patrons

Capítol 25 — Patrons de Test-Driven Development

Test — com testies el teu programari?
Escriu un test automàtic. Testar canvis no és el mateix que tenir un test.

Test aïllat — com hauria d’afectar-se un grup de tests entre ells?
Per res. Fes tests que puguis executar localment i sovint. Executa’ls tots. Evita efectes secundaris — cada setUp hauria d’executar-se per a un sol test i no crear dependències entre tests. Si no ets capaç de fer-ho, és un símptoma de mal disseny de testing.

Llista de tests — què hauries de testar?
Abans de res, escriu tots els tests. Escriure tota la funcionalitat que vols cobrir és un bon hàbit. En el procés, escriu un marcador P/B als tests futurs per evitar anar al final i tornar al principi.

Test primer — quan hauries d’escriure el test?
Abans d’escriure el codi que s’ha de testar.

Assert primer — quan hauries d’escriure les assertions?
Prova d’escriure-les primer. És una pràctica on ja no necessites pensar en la implementació. Simplifiques totes les múltiples preguntes de funcionalitat en el que el test realment necessita assertir.

Flux d’exemple: [Implementació del test → Assertion real] → [Construcció real → Acció HTTP]

Dades de test — quines dades uses per als tests?
Usa dades que facin els tests fàcils de llegir i seguir. Estàs escrivint el test per una raó, no per a una màquina. Si pots tenir múltiples entrades per a un test simple, fes-ho. No t’aturguis al camí feliç.

Dades evidents — com representes la intenció de les dades?
Inclou resultats estesos i actuals al propi test, i intenta que la relació sigui aparent. No sobreabstragis les dades — deixa que els números expliquin la història.

Capítol 26 — Patrons de Barra Vermella

Aquests patrons responen: quan, on i quan parar d’escriure tests — i quan començar.

Test d’un pas — quin test hauries de triar a continuació?
Tria un test que estiguis segur que pots implementar. No hi ha el correcte — et sorprendràs perquè descobreixes el que pots fer fent-ho.

Tests d’inici — quin test hauries d’escriure primer?
Comença testant una variant d’una operació que no fa res. Tria entrades i sortides que siguin fàcils de descobrir. Un primer test fàcil hauria de ser: quin és el mètode/operació més bàsic, i quina hauria de ser la seva sortida.

Test d’explicació — com estens TDD en un equip?
Demana i dona explicacions. El millor disseny i resultats mostraran el model superior de TDD.

Test d’aprenentatge — quan escrius un test per a programari produït externament?
No el mockeges — usa una biblioteca existent que instanciï la dependència externa. Escriu un test al voltant del punt d’integració.

Un altre test — com mantens una distracció tècnica fora del teu flux?
Quan sorgeix una idea temporal, afegeix un test a la llista i continua. Escriu-la.

Test de regressió — quina és la primera cosa que fas quan es reporta un bug?
Escriu el test més petit possible que exposi el bug i fallarà fins que s’arregli. Si tens moltes regressions, és un senyal que les teves decisions de disseny necessiten revisió.

Respiració — et sents cansat?
Descansa. Les idees tornaran i no s’aniran. TDD fomenta un ritme constant: descans, distincions clares, cadència regular.

Torna a fer-ho — què fas quan et sents perdut?
Llença el codi i comença de nou.

Escriptori barat, cadira bona — aconsegueix una cadira realment bona. Mantén el teu escriptori net perquè el teclat pugui resoldre els descansos.

Capítol 27 — Patrons de Testing

Aquests patrons són tècniques més orientades al detall per escriure tests.

Test fill — com fas funcionar un cas de test que resulta ser massa gran?
Escriu un cas de test més petit que representi la peça trencada. Fes funcionar el cas de test més petit, llavors reintrodueix el cas de test més gran.

Mock Object — com escrius un test que depèn d’un recurs complicat?
Crea una versió falsa del recurs que retorni constants. L’exemple clàssic: una base de dades. El teu test hauria d’executar-se sempre localment sense dependre de res extern. Un mock ben dissenyat et dona rendiment, fiabilitat i llegibilitat. Usa una biblioteca de mocks — no escriguis la teva pròpia a menys que estiguis aprenent.

Self Shunt — com testies que un objecte es comunica correctament amb un altre?
Fes que l’objecte sota test es comuniqui amb el propi cas de test en lloc del col·laborador real. Pots afegir un camp count que fa un seguiment de quantes vegades es va cridar un mètode, llavors assertir sobre ell.

Log String — com testies que una seqüència de missatges es crida correctament?
Manté un registre en una cadena i afegeix-hi quan es crida un missatge. Si no t’importa l’ordre, usa el mètode de “soft check” (conteniment de conjunt). Ambdós són patrons anti-corrupció.

Crash Test Dummy — com testies el codi de gestió d’errors que és poc probable que es desencadeni?
Crea un mock que llanci una excepció i verifica l’assertion.

Test trencat — com deixes una sessió de programació amb un test inacabat?
Deixa el test trencat. Quan tornis, tindràs un lloc obvi per on començar. Un test trencat no significa que el programador ha fallat — simplement fa explícit l’estat del programa.

Check-in net — com deixes una sessió quan programes en equip?
Deixa tots els tests funcionant. Comença des d’un lloc de confiança — assegura’t que tots els tests passen abans de fer check-in del codi.

Capítol 28 — Fes-ho fals fins que ho facis real (Patrons de Barra Verda)

Fes-ho fals — quin és el teu primer pas quan tens un test trencat?
Retorna una constant. Després, refactoritza-la cap a una implementació real. El test està ben escrit si és honest.

Té 2 efectes principals:

Psicològic: tenir ràpidament una barra verda et dona un lloc on estar
Control d’abast: et dona la capacitat de resoldre’s ràpidament — un petita passada ajudarà millor a l’extensió

Triangulació — com impulses l’abstracció amb tests de la forma més conservadora?
Abstreu només quan tens 2 o més exemples. Els passos creen un disseny entre la primera solució (constant) i la implementació completa (la matemàtica real). Això et dona una millor comprensió de com implementar el test.

Implementació òbvia — quina és la teva operació òbvia? Simplement fes-la.
Si ets prou confiat, fes la implementació òbvia directament. Però recorda: has de mantenir l’especificació del test. Si comets un error, el test et dirà.

Capítol 29 — Patrons xUnit

Fixture extern — com alliberes recursos externs?
Usa tearDown per alliberar-los. L’objectiu: deixa el món en el mateix estat que abans que s’executés el test.

Mètode de test — com representes un cas de test simple?
Nomina’l clarament. Sense noms clars, no hi ha manera de saber el que s’ha testat. Els frameworks de testing proporcionen noms llegibles — usa’ls per fer el test un “test”.

Test d’excepció — com testies excepcions esperades?
Captura les excepcions esperades i ignora-les. Si l’excepció no es llança, el test falla.

Tots els tests — com executes totes les suites de tests?
Fes una suite de totes les suites. No les separis per paquets — agrega els tests del paquet per a tota l’aplicació. Les classes de test haurien de compartir el mateix paquet que la implementació.

Capítol 30 — Patrons de Disseny

La majoria de problemes que resolem estan connectats a les eines que usem. Els patrons següents són els més rellevants per a la combinació TDD — proporcionen just suficient disseny per dur-te a través dels exemples.

Command — representa la invocació d’un càlcul com un objecte, no com un simple missatge. Quan necessites que la invocació sigui més controlable i manipulable que un missatge, crea un objecte que representi el càlcul.

Value Object — evita problemes d’aliasing fent objectes els valors dels quals no canvien mai un cop creats. Cada operació retorna un objecte nou i net, deixant l’original sense canvis.

Null Object — representa el cas base d’un càlcul com un objecte. Crea un objecte que representi el model per al cas especial en lloc d’usar null.

Template Method — representa una seqüència invariant d’un càlcul amb un mètode abstracte. Escriu un mètode expressat en termes d’altres mètodes abstractes. El mètode ‘normal’ es declara dins de la classe com l’abstracció principal, similar als mètodes privats.

Pluggable Object — representa la variació donant a un altre objecte dues o més implementacions. Quan treballes en una classe amb branques condicionals alternatives, el Pluggable Object et dona una manera de crear sub-objectes que encapsulen aquelles condicions — assegurant que les condicions if no es dupliquen.

Pluggable Selector — evita subclasses invocant dinàmicament mètodes diferents per a instàncies diferents. Emmagatzema el nom d’un mètode i invoca’l dinàmicament. Usa aquest patró amb precaució — redueix el nombre de subclasses però fa el codi més difícil de navegar perquè el mètode que s’invoca no és visible al lloc de crida. Beck recomana l’herència per a la majoria de casos.

Factory Method — crea un objecte cridant un mètode en lloc d’un constructor. Introduint una nova forma de creació a un mètode d’una altra classe, controles el tipus d’objecte retornat.

Impostor — introdueix variació introduint una nova implementació d’un protocol existent. Introdueix un nou objecte amb el mateix protocol que un existent però una implementació diferent. Aquest és el patró darrere del Null Object i del Mock Object — ambdós són Impostors que introdueixen una nova implementació sense canviar la interfície vista pel que crida.

Composite — representa la composició del comportament d’una llista d’objectes com un sol objecte. Fes que l’objecte compost sigui un Impostor per als objectes composats. Crea un nou objecte que encapsuli el tipus de la llista d’objectes.

Collecting Parameter — passa un paràmetre per agregar resultats d’un càlcul a través d’objectes. Per a Composite: implementa un mètode collect. Acumula resultats afegint un paràmetre a l’operació per a la qual es recolliran resultats. Afegir un Collecting Parameter és una conseqüència comuna de Composite.

Capítol 31 — Refactoring

Aquests patrons descriuen com canviar el disseny un cop els tests passen.

Reconcilia diferències — com unifiques dos trossos de codi d’aspecte similar?
Apropa’ls gradualment. A mesura que es fan més similars, fusiona’ls. L’enfocament: apropar-ho per herència o composició.

Aïlla el canvi — com canvies una part d’un mètode o objecte de múltiples parts?
Aïlla la part que ha de canviar. L’aïllament es pot fer extraient o introduint un nou mètode.

Migra dades — com passes d’una representació a una altra?
Duplica temporalment les dades. Si uses un nou tipus, duplica les dades i adapta la nova implementació. Després, elimina la implementació antiga.

Extreu mètode — com fas que un mètode llarg i complicat sigui fàcil de llegir?
Extreu-ne una petita part en un mètode separat i crida’l. Un mètode té 1 i només 1 responsabilitat.

Mètode inline — com simplifiques fluxos de control massa enredats?
Substitueix una invocació de mètode pel cos del mètode. El mètode inline et diu que pots usar el resultat disponible d’un mètode, assignant-lo a una variable.

Extreu interfície — com introdueixes una separació neta d’operacions?
Crea una interfície que contingui les operacions clares. Abstreu el component que vols separar.

Mou mètode — com mous un mètode on li pertoca?
Afegeix-lo a la classe on pertany, llavors elimina’l d’on estava. Si vols moure només una part: primer extreu la part, llavors mou-la.

Method Object — com representes un mètode complicat que requereix molts paràmetres i variables locals?
Fes un objecte del mètode. Crea un objecte amb els mateixos paràmetres que el mètode. Fes que les variables locals siguin variables d’instància. Crea un mètode que executi la lògica. Això promou un nou disseny per al teu sistema.

Afegeix paràmetre — afegir un paràmetre a un nou mètode és un pas d’extensió.

Paràmetre de mètode a paràmetre de constructor — si passes el mateix paràmetre a diversos mètodes diferents del mateix objecte, simplifica l’API passant-lo al constructor una sola vegada.

Notes personals: TDD amb herència i composició

Quan fas TDD amb TDD (meta!), pots trobar-te en una situació de composició on necessites fer totes les teves classes refinament i abstracció.

Dos enfocaments:

Classe abstracta — crea una classe abstracta que contingui la lògica comuna. Els detalls estan a les subclasses. La classe segueix sent abstracta, amb la instanciació a les classes concretes.
Composició — crea una interfície que defineixi tots els mètodes i fes les implementacions necessàries.

Si vols anar amb la 1a opció, testa la lògica comuna a la classe abstracta directament. Els tests poden ser comuns, però els mocks són necessaris. La classe abstracta necessita tots els “mètodes mock” organitzats als seus interns.

Si uses el 2n mètode (composició): tindràs tots els tests de mètode fets. Tens una capa d’abstracció i fas el codi més llegible. La interfície no pot ser un bon model inicial per la manca de tipus als seus mètodes.

La meva recomanació: usa TDD estàndard a les implementacions concretes primer, llavors identifica els tests comuns i mockeja. Executa tots aquells tests des del test de la classe abstracta.

Capítol 32 — Dominar TDD

Quina mida han de tenir els teus passos?

Depenent de quanta difusió hauria de tenir cada test. Passos petits — no sempre es recomana. Però TDD té moltes opcions. L’expansió automàtica ocorre quan es fa referència al refactoring de l’IDE.

Què no has de testar?

Totes les responsabilitats: no càlculs ni test
Fórmules estàndard, bucles, operacions, polimorfisme

Com saps si tens bons tests?

Evita unir codi més llarg i no facis petits whens. Si tens moltes assertions, pensa en el teu disseny — o usa’n una sola.
No escriguis tests que necessitin molt de temps per executar-se. Intenta dividir-los.
Els tests que trenquen parts pitjors després de canviar una secció són un símptoma d’una altra part del codi.

Com porta TDD als límits?

Si tendixes a ser més realista, fes un test d’integració amb garanties naturals. L’objecte que té qualsevol tipus d’interacció serà necessari de nou amb els seus propis paràmetres. El test et dirà el que cal usar de nou als altres objectes.

Quanta sortida necessites?

Escriu tants tests com sigui necessari fins que tots els resultats de les dades de test estiguin coberts. Pensa-hi com a documentació viva. Sigues pragmàtic — els tests estan llests per proporcionar valor ocult.

Quan hauries d’eliminar tests?

Elimina els redundants i duplicats
NO eliminis tests que proporcionen valor i confiança clars
Un test amb el mateix camí a través del codi però que parla de situacions/paràmetres diferents val la pena mantenir-lo

Com influeix el llenguatge de programació en TDD?

Amb les eines modernes, no hauria d’afectar gaire. Potser usar ports o tipus podria estalviar alguns tests. Com més dur és el llenguatge de programació, més necessàriament apareix el testing.

Pots fer TDD en sistemes enormes?

Sí. Fent TDD correctament, el test evolucionarà a mesura que facis implementacions més grans.

Pots fer el desenvolupament amb tests automàtics només?

Necessites més que tests unitaris. També cal testar aplicacions per monitoritzar correctament els resultats — aquí és on entra ATDD (Acceptance Test Driven Development). Els tests d’acceptació representen el camí complet d’una funcionalitat com a objectiu. Descriuen el comportament del domini des de fora.

Com canvies a TDD si no ho estàs fent?

Decideix el moment del canvi — el lloc ha de ser el correcte
Aprèn les eines. Familiaritza’t amb les dependències de test
Després, introdueix-ho gradualment a les noves funcionalitats

Per a qui és TDD?

Cada pràctica de programació necessita un sistema de valors per millorar. TDD ha de venir com una suposició que: si escrius millor codi, tindràs més èxit. TDD t’ajuda a prestar atenció a les coses correctes en el moment correcte, de manera que puguis fer dissenys més nets i millorar a mesura que aprens. TDD és per a qualsevol que vulgui un vincle professional amb el codi. A mesura que practiques, guanyes confiança en el comportament del sistema.

Està TDD limitat a certes condicions?

En molts casos, si un mètode hauria de romandre viu en un camí de test, continua la implementació. Para en passos.

Pensa en el que vols que faci el sistema i deixa que el disseny es classifiqui naturalment a partir de les regles.

Exemple: Iterant

Escriu test per capturar el comportament
Implementa’l
Valora tenir-lo com voldries
Implementa’l
Hauria de ser el test + (2, 3, n…) — El test et diu que cal refactoritzar i implementar estratègies

Per què funciona TDD?

Un desordre sempre redueix la confiança en el teu codi i en el de l’equip
Obtens més feedback a través de millors tests
Adopta pràctiques de programació que atrauen competència

Com es relaciona TDD amb Extreme Programming?

Particular: el test et dona un focus/pla comú
Treballar net: amb el test, és un excel·lent punt de control per continuar
Integració contínua: el test fa una excel·lent recursió, permetent integrar més sovint. Després d’un punt de control de test satisfactori, fes el check-in.
Disseny simple: afegint només el que necessites i eliminant duplicats, aconsegueixes el disseny més simple
Refactoring: eliminant duplicació (1, 2, n…) eliminant el bucle de sintaxi comú antic
Lliurament continu: garantint confiança en bon codi. Centra’t més en les funcionalitats perquè tots els tests s’executen i el codi compila. Això és ATDD.

Còpia de patrons

La còpia de patrons de codi no és bona programació.

Els patrons sempre s’han d’adaptar al teu propi projecte
Una bona manera: primer copia el patró (biblioteca) tan fidelment com sigui possible
Segon: usa alguna barreja de refactoring o test-what-to-do per a l’adaptació personalitzada

Londres vs Chicago: Dues maneres d’abordar TDD

Escola de Londres (Outside-In): Comença des de fora (el test d’acceptació) i treballa cap endins. Mocke molt els col·laboradors. Se centra en les interaccions i els missatges entre objectes.
Escola de Chicago (Inside-Out / Clàssic): Comença des de dins (la lògica de domini central) i construeix cap a fora. Evita mocks on sigui possible. Se centra en l’estat i el comportament.

Cap és incorrecte. El llibre (Kent Beck) segueix l’escola Clàssica/Chicago. Tria basant-te en el teu context.

Pàgines Originals

Fes clic a qualsevol imatge per veure-la a mida completa.