checkmk - Bulutta Çevrimiçi

Program:

ADI

checkmk - Check Unit testinde kullanılmak üzere C birim testleri oluşturmak için Awk komut dosyası
çerçeve.

SİNOPSİS

kontrol etmek [ temiz_mod=1 ] [ giriş dosyası ]

TANIM

Kontrol birimi testiyle kullanım için birim testleri içeren C dili kaynak dosyaları oluşturun
çerçeve. Bu betiğin amacı, tipik ortak olanlardan bazılarını otomatikleştirmektir.
Check kullanarak bir test takımı yazarken yazmalıdır: özellikle, bir
SRunner, Suite(ler) ve TCase(ler) ve bu nesneler arasındaki ilişkilerin oluşturulması
ve test fonksiyonları.

Bu araç, Kontrol ünitesi testine aşina olanlar tarafından kullanılmak üzere tasarlanmıştır.
çerçeve. Bu kılavuz boyunca çerçeveye aşinalık varsayılacaktır.

Kontrol çerçevesi, bununla ilgili bilgilerle birlikte şu adreste mevcuttur:
http://check.sourceforge.net/ <URL:http://check.sourceforge.net/>.

The giriş dosyası argüman kontrol etmek bildirmek için basit, C-önişlemci benzeri bir sözdizimi kullanır
test işlevleri ve bunların Check'teki Süitler ve TCase'lerle ilişkilerini açıklamak için.
kontrol etmek daha sonra bu bilgiyi otomatik olarak yazmak için kullanır. ana() hepsini içeren fonksiyon
gerekli bildirimler ve test takımlarını çalıştırmak için gereken kod ne olursa olsun. NS
nihai C dili çıktısı şu şekilde yazdırılır: kontrol etmekstandart çıktı.

Oluşturulan dosyaya kullanıcı kodunun eklenmesi için olanaklar sağlanmıştır. ana() fonksiyonu,
kütük, test fikstürleri veya özel çıkış değerlerinin kullanımını sağlamak.

atlamak mümkün olsa da giriş dosyası argüman kontrol etmek ve giriş dosyasını sağlayın
on kontrol etmek'nin standart girdisi yerine, genellikle bunu bir giriş olarak sağlamanız önerilir.
argüman. Bunu yapmak kontrol etmek dosyanın adından haberdar olmak, referansları yerleştirmek için
C dili çıktısının ilk yorumlarında ve C #line direktiflerini serpiştirmek için
baştan sona, kullanıcıyı orijinaline yönlendirerek hata ayıklama problemlerini kolaylaştırmak için
giriş dosyası.

SEÇENEKLER

Resmi olarak desteklenen tek seçenek gerçek bir değer belirlemektir (Awk'ın tanımını kullanarak
değişken için "true" için temiz_mod. Bu neden olur kontrol etmek uygun yerleştirmemek
Kaynak koddaki #line yönergeleri, bazılarının gereksiz dağınıklık olduğunu düşünebilir.

Yazar, C derleyicilerine neden olacağı için bu seçeneğin kullanılmasını önermemektedir.
yerine otomatik olarak oluşturulan çıktıdaki satırlara atıfta bulunmak için hata ayıklama araçları
orijinal girdi dosyaları kontrol etmek. Bu, kullanıcıları çıktı dosyalarını düzenlemeye teşvik eder
orijinal girdi dosyaları yerine, akıllı editörler veya
Düzenlemek için doğru dosyayı çeken IDE'ler ve düzeltmelerin üzerine yazılmasına neden olabilir
çıktı dosyaları yeniden oluşturulduğunda.

#line yönergeleri, giriş dosyası standart olarak sağlandığında otomatik olarak bastırılır.
komut satırı argümanı yerine girdi.

KLASİK ÖRNEK

En temel biçiminde, bir girdi dosyası basitçe bir önsöz ve bir test işlevi olabilir.
İlk test işlevinden önce görünen her şey giriş bölümündedir ve
çıktıya kelimesi kelimesine kopyalanır. Test işlevi şu şekilde bir satırla başlatılır:

#Ölçek test_adı

Nerede test_adı test işlevinizin adıdır. Bu, bir C işlevini adlandırmak için kullanılacaktır,
bu nedenle geçerli bir C tanımlayıcısı olmalıdır.

İşte küçük, eksiksiz bir örnek:

--------------------------------------------------
/* Tam bir test örneği */

#Dahil etmek

#testi_testi
int nc;
const char msg[] = "\n\n Merhaba dünya!\n";

nc = printf("%s", mesaj);
ck_assert(nc == (sizeof(mesaj) - 1)); /* NUL'u sonlandırmak için. */
--------------------------------------------------

Yukarıdakileri adlı bir dosyaya yerleştirirseniz basic_complete.ts kullanarak işleyin ve
aşağıdaki komut:

$ kontrol etmek basic_complete.ts > basic_complete.c

basic_complete.c şuna benzer bir çıktı içerecektir:

--------------------------------------------------
/*
* BU DOSYAYI DÜZENLEMEYİN. checkmk tarafından oluşturuldu.
* Bunun yerine orijinal kaynak dosyayı "in" olarak düzenleyin.
*/

#Dahil etmek

/* Tam bir test örneği */

#Dahil etmek

START_TEST(the_test)
{
int nc;
const char msg[] = "\n\n Merhaba dünya!\n";

nc = printf("%s", mesaj);
ck_assert(nc == (sizeof(mesaj) - 1)); /* NUL'u sonlandırmak için. */
}
END_TEST

int main (void)
{
Suite *s1 = suite_create("Çekirdek");
TCase *tc1_1 = tcase_create("Çekirdek");
SRunner *sr = srunner_create(s1);
int nf;

suite_add_tcase(s1, tc1_1);
tcase_add_test(tc1_1, the_test);

srunner_run_all(sr, CK_ENV);
nf = srunner_ntests_failed(sr);
srunner_free(sr);

dönüş nf == 0 ? 0: 1;
}
--------------------------------------------------

Gerçek kullanımda, basic_complete.c #line yönergelerini de içerir.

DİREKTİF ÖZET

Burada anlaşılan tüm C-önişlemci tarzı direktiflerin tam bir özeti bulunmaktadır.
by kontrol etmek. Daha fazla ayrıntı için aşağıya bakın.

# Ölçek test_adı
# test sinyali(işaret) test_adı
# test-çıkış(çıkış_kodu) test_adı
# test döngüsü(başlama, son) test_adı
# test döngüsü sinyali(işaret, başlama, son) test_adı
# test döngüsünden çıkış(çıkış_kodu, başlama, son) test_adı
# süit TestSuiteAdı
# küçük harf TestVaka Adı
# ana-ön
# ana gönderi

Tüm yönergeler büyük/küçük harfe duyarsızdır. Satırın başında boşluk görünebilir
# işaretinden önce, # ile yönerge arasında, yönerge ile herhangi bir argüman arasında ve
satırın sonunda.

TEST TANIMLAMA YÖNERGELER

Testi tanımlamak için kullanılabilecek direktiflerin daha ayrıntılı bir açıklaması burada
fonksiyonlar ve bunların kapları.

TEST FONKSİYONLAR
# Ölçek test_adı
# test sinyali(işaret) test_adı
# test-çıkış(çıkış_kodu) test_adı
# test döngüsü(başlama, son) test_adı
# test döngüsü sinyali(işaret, başlama, son) test_adı
# test döngüsünden çıkış(çıkış_kodu, başlama, son) test_adı

Bunlar, giriş için bir şablon oluşturmaya yönelik en temel yönergelerdir. kontrol etmek. Onlar
gerekli olan tek yönerge: en az bir #test* yönergesi olmalıdır
şablonda görünen veya kontrol etmek bir hata mesajı ile başarısız olur. #test*
Direktifler, her biri yeni bir testin tanımına başlamak üzere birkaç kez belirtilebilir.
fonksiyonu.

The test_adı argüman, C dilinde bir test fonksiyonunun adı olarak kullanılacaktır.
çıktı, bu nedenle geçerli bir C tanımlayıcısı olmalıdır. Yani, bir alfabetik ile başlamalıdır.
karakter veya alt çizgi (_), ardından isteğe bağlı alfasayısal karakterler ve/veya
alt çizgi.

\uXXXX veya
\UXXXXXXXX, burada X'ler onaltılık basamakları temsil eder.

Aynısını belirtmek bir hatadır. test_adı ne olursa olsun birden fazla #test* yönergesinde
farklı test senaryoları veya takımlarıyla ilişkili olup olmadıklarına dair.

olarak kullanılmasından kaçınılması gereken tanımlayıcıların listesi için CHECKMK TANIMLAYICILAR'a bakın.
fonksiyon adlarını test edin.

TEST SUİTLER
# süit TestSuiteAdı

Bu yönerge, test takımının adını belirtir (süit Kontrol testindeki nesne
gelecekteki tüm test senaryolarının (ve test işlevlerinin) ekleneceği çerçeve).

The TestSuiteAdı bir metin dizesidir ve herhangi bir türde karakter içerebilir (diğer
ASCII NUL karakterinden ve yönergeyi sonlandıracak yeni satırdan). Herhangi
test paketi adından baştaki veya sondaki boşluklar çıkarılacaktır.

Yeni bir test takımı başlatmak, aynı zamanda adı yeni ile aynı olan yeni bir test senaryosunu da başlatır.
test odası. Bu test senaryosu adı, sonraki bir #tcase yönergesi tarafından geçersiz kılınabilir.

Bir not süit nesne aslında tarafından tanımlanmayacak kontrol etmek olmadığı sürece C çıktısında
bir noktada bir #test yönergesi tarafından takip edilir (araya giren bir #suite olmadan). O değil
bir #suite için ilişkili #teste sahip olmama hatası; #suite (ve ilişkili herhangi bir
#tcase's) herhangi bir işlemle sonuçlanmayacaktır. kontrol etmek (ve bu nedenle
kullanışsız).

Bir #suite yönergesinin aynı (büyük/küçük harfe duyarlı) birden çok süiti belirtmesi bir hatadır.
kez, önceki kullanımlar en az birinin mevcudiyeti ile somutlaştırılmamışsa
ilişkili #test yönergesi.

İlk #test yönergesinden önce bir #suite yönergesi belirtmezseniz, kontrol etmek
"Çekirdek" dizesiyle örtük bir #suite yönergesinin eşdeğerini gerçekleştirir.
değeri TestSuiteAdı (bu ayrıca bir "Çekirdek" test durumu nesnesi anlamına gelir). Bu
yukarıda TEMEL ÖRNEK'te gösterilmiştir.

TEST DAVALAR
# küçük harf TestVaka Adı

Bu yönerge, test senaryosunun adını belirtir (TCaz Kontrol testindeki nesne
çerçeve) gelecekteki tüm test işlevlerinin ekleneceği.

#tcase, #suite'e çok benzer bir şekilde çalışır. NS TestVaka Adı bir metin dizesidir,
ve rastgele karakterler içerebilir; ve bir TCaz nesne aslında tanımlanmadıkça
ardından ilişkili bir #test yönergesi gelir.

Bir #tcase yönergesinin aynı (büyük/küçük harfe duyarlı) test senaryosunu belirtmesi bir hatadır.
önceki kullanımlar en azından varlığı ile somutlaştırılmadığı sürece, birden çok kez
bir ilişkili #test yönergesi.

Ayrıca yukarıda açıklanan #suite yönergesine bakın.

KULLANICI KOD IN ANA()

C ana() tarafından otomatik olarak oluşturulur kontrol etmek, gerekli tanımlama SrunnerVar,
süit, ve TCaz' kullanıcı tarafından belirtilen test tanımlayıcı direktifler tarafından gereklidir.

Çoğu durumda, bu tamamen otomatik ana() olduğu gibi oldukça uygundur. Yine de,
kişinin özel kod eklemek isteyebileceği durumlar vardır. ana(). Örneğin,
kullanıcı isterse:

· ile test zaman aşımı değerini değiştirin tcase_set_timeout(),

· Check'in "çatalsız modunu" şu şekilde belirtin: srunner_set_fork_status(),

· bazı test durumları için test fikstürleri kurmak, tcase_add_checked_fixture()
or tcase_add_unchecked_fixture(),

· süit koşucusu için test günlüğü oluşturma srunner_set_log() or srunner_set_xml()ya da

· test takımları çalıştırıldıktan sonra özel tamamlama gerçekleştirin.

Bu amaçlar için #main-pre ve #main-post yönergeleri sağlanmıştır.

ANA() PROLOGUE
# ana-ön

Bu yönergeyi izleyen metin, oluşturulan metnin gövdesine kelimesi kelimesine yerleştirilecektir.
ana() fonksiyon, hemen sonra kontrol etmek'nin kendi yerel değişken bildirimleri ve herhangi bir testten önce
koşu gerçekleşti (aslında, testler arasındaki ilişkilerden bile önce, test
vakalar ve test paketleri kuruldu, ancak bu gerçek çok fazla fark yaratmamalı).
Dan beri kontrol etmek beyanlarını yeni bitirmişse, caizdir, hatta caizdir.
burada özel değişken bildirimleri yapmak için katı 1990 ISO C yönergeleri uyarınca.

Daha önce açıklanan yönergelerden farklı olarak #main-pre en fazla bir defa belirtilebilir. Bilişim Teknoloji
#main-post yönergesinden önce gelemez ve #suite, #tcase veya #test yönergesi olamaz
ondan sonra görünebilir.

#main-pre, ayarları değiştirmek veya test fikstürlerini ayarlamak için iyi bir yerdir. tabiki sırayla
Bunu yapmak için hangi isimleri bilmeniz gerekir kontrol etmek somutlaştırmak için kullandı SrunnerVar,
süit, ve TCazVar.

KONTROL MK TANIMLAYICILAR
işaretçiler süit'ler s kalıbı kullanılarak bildirilirX, Burada X ile başlayan bir sayıdır
1 ve sonraki her #suite yönergesi için artırılır. s1 her zaman vardır ve
ilk #test yönergesi tarafından bildirilen test işlevini içerir. Eğer o direktif
önüne #suite gelmezse "Çekirdek" adı verilir.

işaretçiler TCaz'ler tc kalıbı kullanılarak bildirilirX_Y, Burada X karşılık gelir
adı için kullanılan numara süit bunu içerecek TCaz; Ve Y bir sayıdır
her yeni için 1'de başlar süit, ve her biri için artırılır TCaz şöyle süit.

bir işaretçi Srunner sr tanımlayıcısı kullanılarak bildirilir; adında bir tamsayı da var
Test başarısızlıklarının sayısını tutan nf (testler çalıştırıldıktan sonra).

Bariz nedenlerden dolayı, kullanıcı yerel tanımlayıcıları ana(),
veya adları yerel değişkenle çakışabilecek herhangi bir makro veya test işlevi tanımlayın
tarafından kullanılan isimler kontrol etmek. Özetlemek gerekirse, bu isimler şunlardır:

sX

tcX_Y

sr

n.

ANA() SONSÖZ
# ana gönderi

Pek kullanışlı olmasa da, kontrol etmek ayrıca özel eklemek için bir #main-post yönergesi sağlar
sonundaki kod ana(), testler çalıştırıldıktan sonra. Bu temizlemek için kullanılabilir
prologda tahsis edilen kaynaklar veya başarısız olanlarla ilgili bilgileri yazdırmak için
testler veya özel bir çıkış durumu kodu sağlamak için.

Unutmayın, bu yönergeyi kullanırsanız, kontrol etmek irade değil bir iade beyanı sağlayın:
bir tane kendiniz sağlamanız gerekecek.

#main-post yönergesini, aşağıdakiler tarafından tanınan başka yönergeler izleyemez:
kontrol etmek.

KAPSAMLI ÖRNEK

Artık çeşitli direktiflerin ayrıntılı açıklamalarını öğrendiğinize göre, görelim.
hepsi bu oldukça kapsamlı şablonla harekete geçirilir.

--------------------------------------------------
#include "mempool.h" /* MEMPOOLSZ'yi tanımlar, için prototipler
mempool_init() ve mempool_free() */

geçersiz *mempool;

geçersiz mp_setup(geçersiz)
{
mempool = mempool_init(MEMPOOLSZ);
ck_assert_msg(mempool != NULL, "Mempool ayrılamadı.");
}

geçersiz mp_teardown(geçersiz)
{
mempool_free(bellek havuzu);
}

/* girişin sonu */

#suite Mempool

#tcase MP Başlatma

#test mempool_init_zero_test
not havuzu = mempool_init(0);
ck_assert_msg(mempool == NULL, "Sıfır boyutlu bir bellek havuzu ayrıldı!");
ck_assert_msg(mempool_error(), "Sıfır tahsis için bir hata alınmadı.");

/* "MP Util" TCase, kontrol edilen fikstürü kullanır. */
#tcase MP Kullanımı

#test mempool_copy_test
geçersiz *cp = mempool_kopyası(bellek havuzu);
ck_assert_msg(cp != NULL, "Mempool kopyalaması gerçekleştirilemedi.");
ck_assert_msg(cp != mempool, "Kopya orijinal işaretçiyi döndürdü!");

#test mempool_size_test
ck_assert(mempool_getsize(bellek havuzu) == MEMPOOLSZ);

#ana-ön
tcase_add_checked_fixture(tc1_2, mp_setup, mp_teardown);
srunner_set_log(sr, "mplog.txt");

#ana gönderi
eğer (nf != 0) {
printf("Hey, bir sorun var! %d tüm testler başarısız oldu!\n", nf);
}
0 döndür; /* Harness çıktıyı kontrol eder, her zaman başarıyı döndürür
ne olursa olsun. */
--------------------------------------------------

Bunu takmak kontrol etmek, kabaca aşağıdaki gibi bir çıktı alacağız:

--------------------------------------------------
/*
* BU DOSYAYI DÜZENLEMEYİN. checkmk tarafından oluşturuldu.
* Bunun yerine "comprehensive.ts" orijinal kaynak dosyasını düzenleyin.
*/

#Dahil etmek

#include "mempool.h"

geçersiz *mempool;

geçersiz mp_setup(geçersiz)
{
Kendi ID’n ile mağazalarını oluştur
}

geçersiz mp_teardown(geçersiz)
{
Kendi ID’n ile mağazalarını oluştur
}

/* girişin sonu */

START_TEST(mempool_init_zero_test)
{
Kendi ID’n ile mağazalarını oluştur
}
END_TEST

START_TEST(mempool_kopya_testi)
{
Kendi ID’n ile mağazalarını oluştur
}
END_TEST

START_TEST(mempool_size_testi)
{
Kendi ID’n ile mağazalarını oluştur
}
END_TEST

int main (void)
{
Suite *s1 = suite_create("Mempool");
TCase *tc1_1 = tcase_create("MP Başlatma");
TCase *tc1_2 = tcase_create("MP Util");
SRunner *sr = srunner_create(s1);
int nf;

/* Kullanıcı tanımlı ön çalıştırma kodu */
tcase_add_checked_fixture(tc1_2, mp_setup, mp_teardown);
srunner_set_log(sr, "mplog.txt");

suite_add_tcase(s1, tc1_1);
tcase_add_test(tc1_1, mempool_init_zero_test);
suite_add_tcase(s1, tc1_2);
tcase_add_test(tc1_2, mempool_copy_test);
tcase_add_test(tc1_2, mempool_size_test);

srunner_run_all(sr, CK_ENV);
nf = srunner_ntests_failed(sr);
srunner_free(sr);

/* Kullanıcı tanımlı çalıştırma sonrası kod */
eğer (nf != 0) {
printf("Hey, bir sorun var! %d tüm testler başarısız oldu!\n", nf);
}
0 döndür; /* Harness çıktıyı kontrol eder, her zaman başarıyı döndürür
ne olursa olsun. */
}
--------------------------------------------------

onworks.net hizmetlerini kullanarak checkmk'yi çevrimiçi kullanın