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, genellikleassert(...)
veyaassert.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ığı sizeassert.equal
ve Sırasıylaassert.strictEqual
.
- JavaScript, tam (
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 genellikledeepEqual
veyadeepStrictEqual
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.
Ç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:
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', () => { … });