Meslekte kullanılan araçlar

Otomatik testler, temel olarak bir hataya neden olan veya hatalı işlem yapan bir koddur. bir şeyler ters gitti. Çoğu kitaplık veya test çerçevesi çeşitli daha kolay yazılmasını sağlayan temel öğelerdir.

Önceki bölümde belirtildiği gibi, bu temel öğeler neredeyse her zaman bir bağımsız testleri (test senaryoları olarak adlandırılır) tanımlamanın ve onaylarıdır. İddialar, bir sonucu kontrol etme ve sonuca ulaştırmanın bir yoludur. bir şey yanlışsa ve bu tüm öğelerin en temel ilkesi olarak kabul edilebilir ele alacağız.

Bu sayfada, bu temel öğelere genel bir yaklaşım ele alınmaktadır. Seçtiğiniz çerçeve muhtemelen böyle bir şey vardır, ancak bu tam bir referans değildir.

Örneğin:

import { fibonacci, catalan } from '../src/math.js';
import { assert, test, suite } from 'a-made-up-testing-library';

suite('math tests', () => {
  test('fibonacci function', () => {
    // check expected fibonacci numbers against our known actual values
    // with an explanation if the values don't match
    assert.equal(fibonacci(0), 0, 'Invalid 0th fibonacci result');
    assert.equal(fibonacci(13), 233, 'Invalid 13th fibonacci result');
  });
  test('relationship between sequences', () => {
    // catalan numbers are greater than fibonacci numbers (but not equal)
    assert.isAbove(catalan(4), fibonacci(4));
  });
  test('bugfix: check bug #4141', () => {
    assert.isFinite(fibonacci(0)); // fibonacci(0) was returning NaN
  })
});

Bu örnek, "matematiksel" adlı bir test grubu (bazen paket olarak da adlandırılır) oluşturur testleri bulunur" ve her biri birtakım onaylamalar gerçekleştiren üç bağımsız test durumu tanımlar. Bu test durumları genellikle ayrı ayrı ele alınabilir veya örneğin, filtre işaretini kullanın.

Temel öğeler olarak iddia yardımcıları

Vitest dahil olmak üzere çoğu test çerçevesi, bir onay koleksiyonu içerir. döndürülen değerleri hızlı bir şekilde kontrol etmenize olanak tanıyan assert nesnesindeki yardımcılar veya beklentilere karşı koyan başka eyaletler de vardır. Bu beklenti genellikle "iyi olarak bilinir" değerler. Yukarıdaki örnekte, 13. Fibonacci sayısının 233'ü kullanarak bunu doğrudan assert.equal kullanarak onaylayabiliriz.

Ayrıca bir değerin belirli bir biçimde olması, veya başka bir değerden daha yüksek olabilir. Bu kursta olası onay yardımcılarının tamamını kapsar ancak test çerçeveleri her zaman en azından aşağıdaki temel kontrolleri sağlayın:

  • Bir "doğruluk" onay işareti, genellikle 'ok' bir koşulun doğru olup olmadığını kontrol eder. bir şeyin başarılı olup olmadığını kontrol eden bir if doğru. Bu, genellikle assert(...) veya assert.ok(...) olarak sağlanır ve tek bir değer ve isteğe bağlı bir yorum alır.

  • Matematik testi örneğindeki gibi bir eşitlik kontrolü testinde bilinen iyi bir değere eşit olacak şekilde bir nesnenin değerini veya durumunu döndürür. Bunlar, temel eşitlik (sayılar ve dizeler için gibi) veya referans eşitlik (bunlar aynı nesne mi?) İşin mutfağında, bunlar yalnızca bir "gerçeği". kontrol etmek == veya === karşılaştırmasıyla.

    • JavaScript, tam (==) ve katı (===) eşitliği birbirinden ayırt eder. Çoğu test kitaplığı size assert.equal ve Sırasıyla assert.strictEqual.
  • Eşitlik kontrollerini genişleten derin eşitlik kontrolleri nesnelerin, dizilerin ve diğer daha karmaşık veri türlerinin içeriklerinin yanı sıra dahili mantığı kullanarak nesneleri karşılaştırabilirsiniz. Bunlar önemlidir çünkü JavaScript'in bu dosyaların içeriğini iki nesne veya dizi olabilir. Örneğin, [1,2,3] == [1,2,3] her zaman yanlıştır. Test et çerçeveler genellikle deepEqual veya deepStrictEqual yardımcılarını içerir.

İki değeri karşılaştıran onaylama yardımcıları (yalnızca "doğruluk" kontrolü yerine) genellikle iki veya üç bağımsız değişken alır:

  • Test edilen koddan oluşturulan veya durumu seçin.
  • Genellikle sabit kodlu olan beklenen değer (örneğin, düz bir sayı veya dizesi) seçin.
  • Nelerin beklendiğini veya nelerin başarısız olabileceğini açıklayan isteğe bağlı bir yorum, Bu satır başarısız olursa eklenir.
ziyaret edin.

Çeşitlilik yelpazesi oluşturmak için iddiaları birleştirmek çok rastlanan bir durum yoktur çünkü bilgilerinizin sistemetik bir deneyimdir. Örneğin:

  test('JWT parse', () => {
    const json = decodeJwt('eyJieSI6InNhbXRob3Ii');

    assert.ok(json.payload.admin, 'user should be admin');
    assert.deepEqual(json.payload.groups, ['role:Admin', 'role:Submitter']);
    assert.equal(json.header.alg, 'RS265')
    assert.isAbove(json.payload.exp, +new Date(), 'expiry must be in future')
  });

Vitest, Chai onay kitaplığını kullanır destekleyicileri sağlayabilmek için kendi bünyelerinde kodunuza uygun olabilecek iddiaları ve yardımcıları görmek için kullanılır.

Akıcı ve BDD onayları

Bazı geliştiriciler, davranış odaklı olarak adlandırılabilecek bir onaylama tarzını tercih eder geliştirme (BDD) veya Akıcı stil onaylarıdır. Bunlara "beklenti" de denir. yardımcı olur çünkü beklentileri kontrol etme yöntemi expect() olarak adlandırılmıştır.

Yardımcıların, basit bir yöntem olarak yazılan iddialarla aynı şekilde davranmasını bekleyin assert.ok veya assert.strictDeepEquals gibi aramalar yapsa da bazı geliştiriciler bunları daha kolay okunur bulmaktadır. BDD onayı aşağıdaki gibi olabilir:

// A failure here would generate "Expect result to be an array that does include 42"
const result = await possibleMeaningsOfLife();
expect(result).to.be.an('array').that.does.include(42);

// or a simpler form
expect(result).toBe('array').toContainEqual(42);

// the same in assert might be
assert.typeOf(result, 'array', 'Expected the result to be an array');
assert.include(result, 42, 'Expected the result to include 42');

Bu iddia tarzı, yöntem zinciri adı verilen bir teknik sayesinde işe yarar. Burada expect tarafından döndürülen nesne sürekli olarak yöntemini çağırın. to.be ve that.does dahil olmak üzere görüşmenin bazı bölümleri Yukarıdaki örnekte, hiçbir işleve sahip değildir ve yalnızca otomatik bir yorum oluşturmak potansiyel olarak daha kolaydır. başarısız oldu. (expect normalde isteğe bağlı yorumları desteklemez çünkü zincirleme bağlantı, arızayı net bir şekilde açıklamalıdır.)

Birçok test çerçevesi hem Fluent/BDD'yi hem de düzenli onayları destekler. Vitest örneğin, Chai'in yaklaşımları da biraz daha kısa ve öz bir yaklaşımla BDD'ye karşı biraz daha özünde. Jest, Öte yandan, yalnızca beklenti yöntemini kullanın.

Testleri dosyalar arasında gruplandırın

Test yazarken, doğrudan test etmek yerine örtülü gruplamalar yapma eğilimindeyiz. tüm testler tek bir dosyada yapılmak yerine birden çok test dosyasına dosyası olarak da kaydedebilir. Aslında test çalıştırıcıları yalnızca bir dosyanın test amaçlı olduğunu bilirler, çünkü bir filtrenin veya normal ifadenin bir örneğidir. Örneğin vitest, projenizde ".test.jsx" gibi bir uzantıyla biten dosyalar veya ".spec.ts" (".test" ve ".spec" ile geçerli birkaç uzantı) ekleyin.

Bileşen testleri, test edilen bileşenin eş dosyasında yer alır. aşağıdaki dizin yapısında olduğu gibidir:

Bir
  UserList.tsx ve UserList.test.tsx dahil olmak üzere dizini oluşturur.
Bir bileşen dosyası ve ilgili test dosyası.

Benzer şekilde, birim testleri de test edilen kodun yanına yerleştirilir. Uçtan uca testlerin her biri kendi dosyasında olabilir ve entegrasyon testleri de benzersiz klasörlere yerleştirilir. Bu yapılar projenin karmaşık test durumları, kendi test dışı destek dosyalarını gerektirecek şekilde büyür. yalnızca bir test için gereken destek kitaplıklarını ekleyin.

Dosyalar içindeki testleri gruplandırma

Önceki örneklerde olduğu gibi, test çağrısı içine bir test() ile ayarladığınız testleri gruplandıran suite(). Süitler genelde ancak ilgili testleri gruplayarak bir yapı sağlamaya yardımcı olurlar ya da hedeflere yönlendirme işlemini artırır. test() için iletilen yöntem aşağıdaki gibi açıklanır: testin kendi eylemleri.

İfadelerde olduğu gibi, Fluent/BDD'de de İngilizcede gruplandırma testleri. Bazı tipik örnekler aşağıdaki kodda karşılaştırılmıştır:

// traditional/TDD
suite('math tests', () => {
  test('handle zero values', () => {
    assert.equal(fibonacci(0), 0);
  });
});

// Fluent/BDD
describe('math tests', () => {
  it('should handle zero values', () => {
    expect(fibonacci(0)).toBe(0);
  });
})

Çoğu çerçevede suite ve describe test ve expect ile assert arasındaki daha büyük farkların aksine it doğrulama adımını attınız.

Diğer araçlar, paketleri ve testleri düzenlemeye yönelik oldukça farklı yaklaşımlara sahiptir. Örneğin, örneğin, Node.js'nin yerleşik test çalıştırıcısı, test() dolaylı olarak bir test hiyerarşisi oluşturabilirsiniz. Ancak, Vitest yalnızca bu tür uygulamalara izin verir. suite() kullanarak iç içe yerleştiriliyor ve başka bir test() içinde tanımlanan test() çalıştırılmayacak.

Onaylarda olduğu gibi, gruplandırma işleminin tam kombinasyonunun teknoloji yığınınızın sağladığı yöntemlerin o kadar önemli olmadığını öğrenin. Bu kursta, bunları özetlemiş olsanız da, kendi iş akışınızda nasıl araç seçimi.

Yaşam döngüsü yöntemleri

Testlerinizi gruplandırmak için, bir kontrol aralığında, dolaylı olarak en üst düzeyde bile dosyası, her test için veya yalnızca bir defa çalıştırılacak kurulum ve sökme yöntemleri sunmaktır. dönüşüm modellememizdir. Çoğu çerçevede dört yöntem sunulur:

Her "test()" veya "it()" için Süit için bir defa
Test çalıştırmalarından önce "beforeHer()" `beforeAll()`
Test çalıştırmalarından sonra "afterHer()" "afterAll()"

Örneğin, her sanal makineden önce bir sanal kullanıcı veritabanını test edin ve daha sonra temizleyin:

suite('user test', () => {
  beforeEach(() => {
    insertFakeUser('bob@example.com', 'hunter2');
  });
  afterEach(() => {
    clearAllUsers();
  });

  test('bob can login', async () => {  });
  test('alice can message bob', async () => {  });
});

Bu, testlerinizi basitleştirmenize yardımcı olabilir. Bu projede ortak olarak bulunan her testte kopyalamak yerine söküm kodunu yerleştirin. Ayrıca, kurulum ve söküm kodunun kendisi bir hata verir. Bu hata, testlerin başarısız olmasını içermeyen sorunlar.

Genel tavsiye

Bu ilkel elemanları düşünürken aklınızda bulundurmanız gereken birkaç ipucunu aşağıda bulabilirsiniz.

Temel öğeler yol göstericidir

Buradaki ve sonraki birkaç sayfada yer alan araçların ve temel öğelerin Vitest, Jest, Mocha, Web Test Runner veya başka herhangi bir çerçeve oluşturmanıza yardımcı olur. Vitest'i genel rehber olarak kullanmış olsak da, mutlaka bu stratejileri kullanabilirsiniz.

Onayları gerektiği şekilde karıştırıp eşleştirin

Testler, temelde hata gönderebilen kodlardır. Her koşucu, farklı test durumlarını tanımlamak için temel, muhtemelen test().

Ancak bu koşucu assert(), expect() ve onay yardımcıları da sağlıyorsa Bu bölümün daha çok kolaylıkla ilgili olduğunu unutmayın. Dilerseniz bu kısmı atlayabilirsiniz. gerekir. Hataya neden olabilecek her türlü kodu çalıştırabilirsiniz. other onay kitaplıkları veya nostaljik bir if ifadesi.

IDE kurulumu hayat kurtarabilir

IDE'nizin, VSCode gibi, otomatik tamamlamaya ve daha üretken olmanızı sağlayabilir. Örneğin, örnek, assert alanında Chai onayında 100'den fazla yöntem vardır eğitim olmalı, gerekli belgeleri sağlamalısınız kullanışlı olabilir.

Bu, özellikle global ad alanını kullanır. Bu küçük bir farktır ama test kitaplıkları, açıksa içe aktarmadan da kullanılabilir. genel ad alanına otomatik olarak eklenir:

// some.test.js
test('using test as a global', () => {  });

Otomatik olarak desteklenseler bile yardımcıları içe aktarmanızı öneririz. çünkü bu, IDE'nize bu yöntemleri aramak için net bir yol sağlar. ( bazı kod tabanlarında sihirli bir görüntü oluşturduğundan, React global, ancak bazıları değildir ve React.)

// some.test.js
import { test } from 'vitest';
test('using test as an import', () => {  });