Testipõhine arendus (TDD) JavaScriptis: Põhjalik juhend globaalsetele arendajatele

Kujutage ette sellist stsenaariumi: teie ülesandeks on muuta kriitilist koodilõiku suures pärandsüsteemis. Te tunnete hirmutunnet. Kas teie muudatus rikub midagi muud ära? Kuidas saate olla kindel, et süsteem töötab endiselt ettenähtud viisil? See hirm muudatuste ees on levinud häda tarkvaraarenduses, mis viib sageli aeglase arengu ja habraste rakendusteni. Aga mis siis, kui oleks olemas viis tarkvara enesekindlalt ehitada, luues turvavõrgu, mis püüab vead kinni enne, kui need kunagi produktsiooni jõuavad? See on testipõhise arenduse (TDD) lubadus.

TDD ei ole pelgalt testimistehnika; see on distsiplineeritud lähenemine tarkvara disainile ja arendusele. See pöörab traditsioonilise „kirjuta kood, siis testi“ mudeli pea peale. TDD-ga kirjutate testi, mis ebaõnnestub, enne kui kirjutate produktsioonikoodi, et see läbiks. Sellel lihtsal ümberpööramisel on sügavad tagajärjed koodi kvaliteedile, disainile ja hooldatavusele. See juhend pakub põhjalikku ja praktilist ülevaadet TDD rakendamisest JavaScriptis, mis on mõeldud professionaalsete arendajate globaalsele auditooriumile.

Mis on testipõhine arendus (TDD)?

Oma olemuselt on testipõhine arendus arendusprotsess, mis tugineb väga lühikese arendustsükli kordamisele. Selle asemel, et kirjutada funktsioone ja neid seejärel testida, nõuab TDD, et test kirjutataks esimesena. See test ebaõnnestub vältimatult, kuna funktsiooni pole veel olemas. Arendaja ülesanne on seejärel kirjutada lihtsaim võimalik kood, et see konkreetne test läbiks. Kui see on läbitud, puhastatakse ja täiustatakse koodi. Seda põhitsüklit tuntakse kui „Red-Green-Refactor“ tsüklit.

TDD rütm: Red-Green-Refactor

See kolmeetapiline tsükkel on TDD südametukse. Selle rütmi mõistmine ja harjutamine on tehnika valdamiseks fundamentaalne.

• 🔴 Red — Kirjuta mittetoimiv test: Alustate uue funktsionaalsuse jaoks automatiseeritud testi kirjutamisega. See test peaks määratlema, mida te tahate, et kood teeks. Kuna te pole veel ühtegi implementatsioonikoodi kirjutanud, on see test garanteeritult mittetoimiv. Mittetoimiv test ei ole probleem; see on edasiminek. See tõestab, et test töötab korrektselt (see suudab ebaõnnestuda) ja seab selge, konkreetse eesmärgi järgmiseks sammuks.
• 🟢 Green — Kirjuta lihtsaim kood testi läbimiseks: Teie eesmärk on nüüd ainus: panna test läbima. Peaksite kirjutama absoluutselt minimaalse hulga produktsioonikoodi, mis on vajalik testi punasest roheliseks muutmiseks. See võib tunduda ebaloogiline; kood ei pruugi olla elegantne ega tõhus. See on okei. Siin on fookus ainult testiga määratletud nõude täitmisel.
• 🔵 Refactor — Täiusta koodi: Nüüd, kui teil on läbiv test, on teil olemas turvavõrk. Saate enesekindlalt oma koodi puhastada ja täiustada, kartmata funktsionaalsuse rikkumist. Siin tegelete halbade koodilõhnadega, eemaldate dubleerimist, parandate selgust ja optimeerite jõudlust. Saate oma testikomplekti käivitada igal hetkel refaktoorimise ajal, et tagada, et te pole lisanud ühtegi regressiooni. Pärast refaktoorimist peaksid kõik testid endiselt rohelised olema.

Kui tsükkel on ühe väikese funktsionaalsuse jaoks lõpule viidud, alustatakse uuesti järgmise osa jaoks uue mittetoimiva testiga.

TDD kolm seadust

Robert C. Martin (tihti tuntud kui „Onu Bob“), agiilse tarkvaraliikumise võtmeisik, määratles kolm lihtsat reeglit, mis kodifitseerivad TDD distsipliini:

1. Te ei tohi kirjutada ühtegi produktsioonikoodi, välja arvatud selleks, et panna läbima mittetoimivat ühiktesti.
2. Te ei tohi kirjutada ühiktesti rohkem, kui on piisav selle mittetoimimiseks; ja kompileerimisvead on mittetoimimised.
3. Te ei tohi kirjutada rohkem produktsioonikoodi, kui on piisav ühe mittetoimiva ühiktesti läbimiseks.

Nende seaduste järgimine sunnib teid Red-Green-Refactor tsüklisse ja tagab, et 100% teie produktsioonikoodist on kirjutatud konkreetse, testitud nõude rahuldamiseks.

Miks peaksite TDD kasutusele võtma? Globaalne äriline põhjendus

Kuigi TDD pakub tohutut kasu üksikutele arendajatele, avaldub selle tõeline jõud meeskonna ja äri tasandil, eriti globaalselt hajutatud keskkondades.

• Suurenenud enesekindlus ja kiirus: Põhjalik testikomplekt toimib turvavõrguna. See võimaldab meeskondadel lisada uusi funktsioone või refaktoorida olemasolevaid enesekindlalt, mis viib kõrgema jätkusuutliku arenduskiiruseni. Kulutate vähem aega käsitsi regressioonitestimisele ja silumisele ning rohkem aega väärtuse loomisele.
• Parem koodidisain: Testide esimesena kirjutamine sunnib teid mõtlema, kuidas teie koodi kasutatakse. Olete omaenda API esimene tarbija. See viib loomulikult paremini disainitud tarkvarani, kus on väiksemad, fokusseeritumad moodulid ja selgem huvide lahusus.
• Elav dokumentatsioon: Globaalse meeskonna jaoks, mis töötab erinevates ajavööndites ja kultuurides, on selge dokumentatsioon kriitilise tähtsusega. Hästi kirjutatud testikomplekt on elava, käivitatava dokumentatsiooni vorm. Uus arendaja saab teste lugedes täpselt aru, mida koodilõik peab tegema ja kuidas see erinevates stsenaariumides käitub. Erinevalt traditsioonilisest dokumentatsioonist ei saa see kunagi aegunuks.
• Vähendatud omamise kogukulu (TCO): Varases arendustsüklis avastatud vead on eksponentsiaalselt odavamad parandada kui need, mis leitakse produktsioonist. TDD loob robustse süsteemi, mida on lihtsam hooldada ja laiendada, vähendades tarkvara pikaajalist TCO-d.

JavaScripti TDD keskkonna seadistamine

TDD-ga alustamiseks JavaScriptis on vaja mõnda tööriista. Kaasaegne JavaScripti ökosüsteem pakub suurepäraseid valikuid.

Testimiskomplekti põhikomponendid

• Testikäivitaja (Test Runner): Programm, mis leiab ja käivitab teie testid. See pakub struktuuri (nagu `describe` ja `it` plokid) ja esitab tulemused. Jest ja Mocha on kaks kõige populaarsemat valikut.
• Väidete teek (Assertion Library): Tööriist, mis pakub funktsioone, et kontrollida, kas teie kood käitub ootuspäraselt. See võimaldab teil kirjutada väiteid nagu `expect(result).toBe(true)`. Chai on populaarne eraldiseisev teek, samas kui Jest sisaldab omaenda võimsat väidete teeki.
• Mockimise teek (Mocking Library): Tööriist sõltuvuste, nagu API-kutsed või andmebaasiühendused, „võltsingute“ loomiseks. See võimaldab teil testida oma koodi eraldiseisvalt. Jestil on suurepärased sisseehitatud mockimise võimalused.

Selle lihtsuse ja kõik-ühes olemuse tõttu kasutame oma näidetes Jesti. See on suurepärane valik meeskondadele, kes otsivad „null-konfiguratsiooniga“ kogemust.

Samm-sammuline seadistamine Jestiga

Seadistame uue projekti TDD jaoks.

1. Initsialiseerige oma projekt: Avage oma terminal ja looge uus projektikataloog.

            mkdir js-tdd-project
cd js-tdd-project
npm init -y
            

              
                Copy
              
            
          

2. Installige Jest: Lisage Jest oma projekti arendussõltuvusena.

            npm install --save-dev jest
            

              
                Copy
              
            
          

3. Konfigureerige testiskript: Avage oma `package.json` fail. Leidke jaotis `"scripts"` ja muutke `"test"` skripti. Samuti on väga soovitatav lisada `"test:watch"` skript, mis on TDD töövoo jaoks hindamatu.

            "scripts": {
  "test": "jest",
  "test:watch": "jest --watchAll"
}
            

              
                Copy
              
            
          

`--watchAll` lipp ütleb Jestile, et see käivitaks testid automaatselt uuesti, kui fail salvestatakse. See annab kohest tagasisidet, mis sobib ideaalselt Red-Green-Refactor tsükliga.

Ongi kõik! Teie keskkond on valmis. Jest leiab automaatselt testifailid, mille nimi on `*.test.js`, `*.spec.js`, või mis asuvad `__tests__` kataloogis.

TDD praktikas: `CurrencyConverter` mooduli ehitamine

Rakendame TDD tsüklit praktilisele, globaalselt mõistetavale probleemile: raha konverteerimine valuutade vahel. Ehitame `CurrencyConverter` mooduli samm-sammult.

Iteratsioon 1: Lihtne, fikseeritud kursiga konverteerimine

🔴 RED: Kirjuta esimene mittetoimiv test

Meie esimene nõue on konverteerida konkreetne summa ühest valuutast teise, kasutades fikseeritud kurssi. Looge uus fail nimega `CurrencyConverter.test.js`.

            // CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

describe('CurrencyConverter', () => {
  it('should convert an amount from USD to EUR correctly', () => {
    // Arrange
    const amount = 10; // 10 USD
    const expected = 9.2; // Assuming a fixed rate of 1 USD = 0.92 EUR

    // Act
    const result = CurrencyConverter.convert(amount, 'USD', 'EUR');

    // Assert
    expect(result).toBe(expected);
  });
});
            

              
                Copy
              
            
          

Nüüd käivitage testide jälgija oma terminalist:

            npm run test:watch
            

              
                Copy
              
            
          

Test ebaõnnestub suurejooneliselt. Jest teatab midagi sarnast: `TypeError: Cannot read properties of undefined (reading 'convert')`. See on meie PUNANE seisund. Test ebaõnnestub, sest `CurrencyConverter` ei eksisteeri.

🟢 GREEN: Kirjuta lihtsaim kood testi läbimiseks

Nüüd teeme testi läbivaks. Looge `CurrencyConverter.js`.

            // CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

Niipea kui selle faili salvestate, käivitab Jest testi uuesti ja see muutub ROHELISEKS. Oleme kirjutanud absoluutselt minimaalse koodi, et rahuldada testi nõuet.

🔵 REFACTOR: Täiusta koodi

Kood on lihtne, kuid me saame juba mõelda täiustustele. Pesastatud `rates` objekt on veidi jäik. Praegu on see piisavalt puhas. Kõige tähtsam on see, et meil on töötav funktsioon, mida kaitseb test. Liigume edasi järgmise nõude juurde.

Iteratsioon 2: Tundmatute valuutade käsitlemine

🔴 RED: Kirjuta test kehtetu valuuta jaoks

Mis peaks juhtuma, kui proovime konverteerida valuutasse, mida me ei tunne? See peaks ilmselt viskama vea. Määratleme selle käitumise uues testis failis `CurrencyConverter.test.js`.

            // In CurrencyConverter.test.js, inside the describe block

it('should throw an error for unknown currencies', () => {
  // Arrange
  const amount = 10;

  // Act & Assert
  // We wrap the function call in an arrow function for Jest's toThrow to work.
  expect(() => {
    CurrencyConverter.convert(amount, 'USD', 'XYZ');
  }).toThrow('Unknown currency: XYZ');
});
            

              
                Copy
              
            
          

Salvestage fail. Testikäivitaja näitab kohe uut ebaõnnestumist. See on PUNANE, sest meie kood ei viska viga; see üritab ligi pääseda `rates['USD']['XYZ']`, mis põhjustab `TypeError`. Meie uus test on selle vea õigesti tuvastanud.

🟢 GREEN: Pane uus test läbima

Muudame `CurrencyConverter.js` faili, et lisada valideerimine.

            // CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92,
    GBP: 0.80
  },
  EUR: {
    USD: 1.08
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    if (!rates[from] || !rates[from][to]) {
      // Determine which currency is unknown for a better error message
      const unknownCurrency = !rates[from] ? from : to;
      throw new Error(`Unknown currency: ${unknownCurrency}`);
    }
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

Salvestage fail. Mõlemad testid on nüüd läbivad. Oleme tagasi ROHELISES seisundis.

🔵 REFACTOR: Puhasta koodi

Meie `convert` funktsioon kasvab. Valideerimisloogika on segatud arvutusega. Võiksime valideerimise eraldada eraldi privaatseks funktsiooniks loetavuse parandamiseks, kuid praegu on see veel hallatav. Võti on selles, et meil on vabadus neid muudatusi teha, sest meie testid annavad meile teada, kui me midagi ära rikume.

Iteratsioon 3: Asünkroonne kursipäring

Kurside käsitsi sisestamine pole realistlik. Refaktoorime oma mooduli, et see hangiks kursse (mockitud) välisest API-st.

🔴 RED: Kirjuta asünkroonne test, mis mockib API-kutset

Esiteks peame oma konverteri ümber struktureerima. See peab nüüd olema klass, mida saame instantseerida, võib-olla API-kliendiga. Peame ka `fetch` API-d mockima. Jest teeb selle lihtsaks.

Kirjutame oma testifaili ümber, et see vastaks uuele, asünkroonsele reaalsusele. Alustame uuesti õnneliku stsenaariumi testimisega.

            // CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

// Mock the external dependency
global.fetch = jest.fn();

beforeEach(() => {
  // Clear mock history before each test
  fetch.mockClear();
});

describe('CurrencyConverter', () => {
  it('should fetch rates and convert correctly', async () => {
    // Arrange
    // Mock the successful API response
    fetch.mockResolvedValueOnce({
      json: () => Promise.resolve({ rates: { EUR: 0.92 } })
    });

    const converter = new CurrencyConverter('https://api.exchangerates.com');
    const amount = 10; // 10 USD

    // Act
    const result = await converter.convert(amount, 'USD', 'EUR');

    // Assert
    expect(result).toBe(9.2);
    expect(fetch).toHaveBeenCalledTimes(1);
    expect(fetch).toHaveBeenCalledWith('https://api.exchangerates.com/latest?base=USD');
  });

  // We'd also add tests for API failures, etc.
});
            

              
                Copy
              
            
          

Selle käivitamine toob kaasa hulga PUNAST. Meie vana `CurrencyConverter` ei ole klass, sellel pole `async` meetodit ja see ei kasuta `fetch`-i.

🟢 GREEN: Rakenda asünkroonne loogika

Nüüd kirjutame `CurrencyConverter.js` ümber, et see vastaks testi nõuetele.

            // CurrencyConverter.js
class CurrencyConverter {
  constructor(apiUrl) {
    this.apiUrl = apiUrl;
  }

  async convert(amount, from, to) {
    const response = await fetch(`${this.apiUrl}/latest?base=${from}`);
    if (!response.ok) {
      throw new Error('Failed to fetch exchange rates.');
    }

    const data = await response.json();
    const rate = data.rates[to];

    if (!rate) {
      throw new Error(`Unknown currency: ${to}`);
    }

    // Simple rounding to avoid floating point issues in tests
    const convertedAmount = amount * rate;
    return parseFloat(convertedAmount.toFixed(2));
  }
}

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

Salvestamisel peaks test muutuma ROHELISEKS. Pange tähele, et lisasime ka ümardamisloogika, et tegeleda ujukomaarvude ebatäpsustega, mis on levinud probleem finantsarvutustes.

🔵 REFACTOR: Täiusta asünkroonset koodi

`convert` meetod teeb palju: pärimine, veakäsitlus, parsimine ja arvutamine. Võiksime selle refaktoorida, luues eraldi `RateFetcher` klassi, mis vastutab ainult API-suhtluse eest. Meie `CurrencyConverter` kasutaks siis seda pärimisklassi. See järgib ühe vastutuse printsiipi ja muudab mõlemad klassid lihtsamini testitavaks ja hooldatavaks. TDD juhatab meid selle puhtama disaini poole.

Levinud TDD mustrid ja antimustrid

TDD-d praktiseerides avastate mustreid, mis töötavad hästi, ja antimustreid, mis tekitavad hõõrdumist.

Head mustrid, mida järgida

• Arrange, Act, Assert (AAA) (Valmista ette, Tegutse, Kinnita): Struktureerige oma testid kolme selgesse ossa. Valmista ette oma seadistus, Tegutse, käivitades testitava koodi, ja Kinnita, et tulemus on õige. See muudab testid kergesti loetavaks ja mõistetavaks.
• Testi ühte käitumist korraga: Iga testjuhtum peaks kontrollima ühte konkreetset käitumist. See teeb ilmselgeks, mis läks katki, kui test ebaõnnestub.
• Kasuta kirjeldavaid testinimesid: Testi nimi nagu `it('should throw an error if the amount is negative')` on palju väärtuslikum kui `it('test 1')`.

Antimustrid, mida vältida

• Implementatsiooni detailide testimine: Testid peaksid keskenduma avalikule API-le („mida“), mitte privaatsele implementatsioonile („kuidas“). Privaatsete meetodite testimine muudab teie testid hapraks ja refaktoorimise keeruliseks.
• Refaktoorimise etapi ignoreerimine: See on kõige levinum viga. Refaktoorimise vahelejätmine toob kaasa tehnilise võla nii teie produktsioonikoodis kui ka testikomplektis.
• Suurte ja aeglaste testide kirjutamine: Ühiktestid peaksid olema kiired. Kui nad sõltuvad reaalsetest andmebaasidest, võrgukutsetest või failisüsteemidest, muutuvad nad aeglaseks ja ebausaldusväärseks. Kasutage mocke ja stub'e oma ühikute isoleerimiseks.

TDD laiemas arenduse elutsüklis

TDD ei eksisteeri vaakumis. See integreerub kaunilt kaasaegsete Agile ja DevOps praktikatega, eriti globaalsete meeskondade jaoks.

• TDD ja Agile: Kasutajalugu või aktsepteerimiskriteerium teie projektijuhtimise tööriistast saab otse tõlkida mitmeks mittetoimivaks testiks. See tagab, et ehitate täpselt seda, mida äri nõuab.
• TDD ja pidev integratsioon/pidev tarnimine (CI/CD): TDD on usaldusväärse CI/CD konveieri alus. Iga kord, kui arendaja lükkab koodi üles, saab automatiseeritud süsteem (nagu GitHub Actions, GitLab CI või Jenkins) käivitada kogu testikomplekti. Kui mõni test ebaõnnestub, peatatakse ehitus, vältides vigade jõudmist produktsiooni. See annab kiire, automatiseeritud tagasiside kogu meeskonnale, olenemata ajavöönditest.
• TDD vs. BDD (Behavior-Driven Development ehk käitumispõhine arendus): BDD on TDD laiendus, mis keskendub koostööle arendajate, kvaliteediinseneride ja ärihuviliste vahel. See kasutab käitumise kirjeldamiseks loomuliku keele formaati (Given-When-Then). Sageli juhib BDD funktsionaalsuse fail mitme TDD-stiilis ühiktesti loomist.

Kokkuvõte: Sinu teekond TDD-ga

Testipõhine arendus on rohkem kui testimisstrateegia—see on paradigma nihe selles, kuidas me läheneme tarkvaraarendusele. See soodustab kvaliteedi, enesekindluse ja koostöö kultuuri. Red-Green-Refactor tsükkel pakub stabiilset rütmi, mis juhatab teid puhta, robustse ja hooldatava koodi poole. Tulemuseks olev testikomplekt muutub turvavõrguks, mis kaitseb teie meeskonda regressioonide eest, ja elavaks dokumentatsiooniks, mis aitab uusi liikmeid sisse elada.

Õppimiskõver võib tunduda järsk ja algne tempo võib tunduda aeglasem. Kuid pikaajalised dividendid vähendatud silumisaja, parema tarkvaradisaini ja suurenenud arendajate enesekindluse näol on mõõtmatud. Tee TDD valdamiseni on distsipliini ja praktika küsimus.

Alusta juba täna. Vali oma järgmises projektis üks väike, mittekriitiline funktsioon ja pühendu protsessile. Kirjuta test esimesena. Vaata, kuidas see ebaõnnestub. Tee see läbivaks. Ja siis, mis kõige tähtsam, refaktoori. Kogege enesekindlust, mis kaasneb rohelise testikomplektiga, ja te imestate varsti, kuidas te kunagi tarkvara teisiti ehitasite.