Test Driven Development

Widzisz wersję archiwalną tematu "Test Driven Development" z forum pl.comp.lang.c

Seweryn Habdank-Wojewódzki - 5 Sty 2006, 06:38

Witam

Mam pytanie jakie są dedykowane narzędzia pod linux/unix'y, aby móc powiedzieć,
że software jest pisany aby spełniać "Test Driven Development".

W szczególności interesują mnie programy do testowania zaawansowanych systemów
obliczeniowych (predyktory, systemy decyzyjne, systemy ekspertowe do data
miningu i KDD, etc.).

A już w ogóle jeśli to może też testować programy mające reżim hard real-time,
to byłoby super.

I ostatnie pytanie czy są jakieś symulatory/testery jak wyglądałyby obliczenia
w gridzie.

Pozdrawiam.

Marcin Hoppe - 5 Sty 2006, 09:17

Mam pytanie jakie są dedykowane narzędzia pod linux/unix'y, aby móc powiedzieć,
że software jest pisany aby spełniać "Test Driven Development".

Oprogramowanie można pisać na modłę TDD nawet bez użycia dedykowanych
narzędzi. Ot, po prostu najpierw pracować nad testami a później dopiero
nad kodem, który te testy spełni. Podejście to nie wymusza stosowania
jakichkolwiek zewnętrznych do danego środowiska wytwórczego cudaków --
można przecież pisać z boczku kod testowy w postaci skryptów Perl
uruchamianych podczas każdej próby zbudowania programu.

Jeśli chodzi o biblioteki wspomagające TDD, np. biblioteki do testów
jednostkowych, to najczęściej są one przeznaczone dla konkretnego języka
programowania lub środowiska (jak Java czy .NET). Nie wydaje mi się,
żeby istniał ogólny tool dla Linuksa/Uniksów.

W szczególności interesują mnie programy do testowania zaawansowanych systemów
obliczeniowych (predyktory, systemy decyzyjne, systemy ekspertowe do data
miningu i KDD, etc.).

A to jest istotnie ciekawe zagadnienie, zwłaszcza w przypadku
równoległego rozwijania metod matematycznych i oprogramowania :).

Wracając jednak do głównego wątku: oprogramowanie obliczeniowe jest w
ogólności najłatwiejsze do testowania. Można przygotować wiele zestawów
danych wejściowych i na boku, ręcznie, opracować akceptowalne odpowiedzi
systemu lub procedury decydujące o akceptacji rozwiązania. I znowu,
można to zrobić za pomocą narzędzia do testów jednostkowych lub po
prostu, jako zestaw skryptów.

A już w ogóle jeśli to może też testować programy mające reżim hard real-time,
to byłoby super.

A tutaj niestety nie mam nic do powiedzenia. W ACM Digital Library są
zdaje się jakieś artykuły na temat testowania systemów real-time.

I ostatnie pytanie czy są jakieś symulatory/testery jak wyglądałyby obliczenia
w gridzie.

Tutaj też niestety nie mam żadnej wiedzy :(.

Seweryn Habdank-Wojewódzki - 5 Sty 2006, 09:38

Witam

Jeśli chodzi o biblioteki wspomagające TDD, np. biblioteki do testów
jednostkowych, to najczęściej są one przeznaczone dla konkretnego języka
programowania lub środowiska (jak Java czy .NET). Nie wydaje mi się,
żeby istniał ogólny tool dla Linuksa/Uniksów.

To znaczy pisząc na grupę o C/C++ miałem na myśli te języki.

| W szczególności interesują mnie programy do testowania zaawansowanych
| systemów obliczeniowych (predyktory, systemy decyzyjne, systemy ekspertowe
| do data miningu i KDD, etc.).
A to jest istotnie ciekawe zagadnienie, zwłaszcza w przypadku
równoległego rozwijania metod matematycznych i oprogramowania :).

U mnie w firmie różne "dziwadła" piszemy, ale jakoś nie widziałem, żeby ktoś na

programu nigdy nie oddajemy.

Wracając jednak do głównego wątku: oprogramowanie obliczeniowe jest w
ogólności najłatwiejsze do testowania. Można przygotować wiele zestawów
danych wejściowych i na boku, ręcznie, opracować akceptowalne odpowiedzi
systemu lub procedury decydujące o akceptacji rozwiązania. I znowu,
można to zrobić za pomocą narzędzia do testów jednostkowych lub po
prostu, jako zestaw skryptów.

I tu jest kłopot, jak w systemie ręcznie wyliczyć np. wektor 200 000 wyników.
Bo tyle ma przykładowy wektor danych do obróbki? W sumie testy polegają na
tym, że:

1. Sprawdzamy czy program działa - nie wywala się, nie ma mem leaków dla
różnych danych wejściowych itp.

2. Sprawdzamy czy wyniki są cicra about poprawne (tu można czasem dać asserty),
ale nie zawsze, bo czasami wyniki mieszczą się w zakresach, ale jak coś jest
źle policzone, to tylko wykres i intuicja pomagają.

No i jak tu automatyzować punkt 2?

Pozdrawiam i dziękuję za dość wyczerpujące rozwianie wątpliwości.

Bronek Kozicki - 5 Sty 2006, 09:58

To znaczy pisząc na grupę o C/C++ miałem na myśli te języki.

korzystam z CPPUnit, ale nie jestem zadowolony. Problem z TDD i C++
polega na tym, że nie znam narzędzi które wspierałyby coś więcej niż
programowanie zorientowane obiektowo, więc stosowanie tych dostępnych
ogranicza Cię do OOP. Wyjściem jest ograniczenie zasięgu testów. Ponadto
CPPUnit nie rozgranicza między testowanie implementacji a całego
modułu - owszem jest ładna hierarchia, ale umieszczanie w niej zarówno
testów wysokiego poziomu jak niskiego poziomu jest niewygodne. Jeżeli
masz swobodę wyboru, może przyjrzyj się testom boost-a ?

Seweryn Habdank-Wojewódzki - 5 Sty 2006, 10:34

Witam

| To znaczy pisząc na grupę o C/C++ miałem na myśli te języki.
Jeżeli masz swobodę wyboru, może przyjrzyj się testom boost-a ?

Mam możliwość wyboru i podjęcia decyzji (oczywiście w obrębie projektu w którym
jestem).

Testy w boost są ok i nawet bardzo ok, bo do obliczeń wystarczą "asserty", a
wyniki to chyba nie ma bata, trzeba analizować ręcznie.

Pozdrawiam.

Tomek - 5 Sty 2006, 14:25

korzystam z CPPUnit, ale nie jestem zadowolony.

Sprobuj CxxUnit - nalepszy jaki uzywalem do tej pory, ale wymaga perla
i troche setupu(wbrew temu co twierdzi autor w dokumentacji
podlaczylem do VC2003 tak zeby automatycznie sie testowalo wszytsko
a komunikaty o bledach wskazywaly na kod zrodlowy)

zbyszekz - 5 Sty 2006, 17:01

Witam

| Jeśli chodzi o biblioteki wspomagające TDD, np. biblioteki do testów
| jednostkowych, to najczęściej są one przeznaczone dla konkretnego języka
| programowania lub środowiska (jak Java czy .NET). Nie wydaje mi się,
| żeby istniał ogólny tool dla Linuksa/Uniksów.
To znaczy pisząc na grupę o C/C++ miałem na myśli te języki

Nie ma znaczenia jaki język,
.

TDD to metodyka tworzenia aplikacji zakładająca stworzenie testów a
następnie budowanie aplikacji tak aby te testy spełniły (maksymalne
uproszczenie TDD).
Metodyka nic nie mówi o tym jak testować, natomiast ważny jest moment
powstania tychże, bo powstają wcześniej niż kod a ten manewr ma zapewnić że
pirwszoplanowym testem będzie spełnienie wymagań użytkownika (testy powstają
na bazie wymagań) a nie sprawdzenie czy aplikacja "chodzi" (bo to jest mało
ważne, jeśli potrzeby użytkownika są zaspokojone).

Zbyszek Malec - 5 Sty 2006, 19:45

Zbyszek Zarzycki

Jej! Cały czas myślę że to ja :(

Zbyszek Zarzycki - 6 Sty 2006, 03:22

| Zbyszek Zarzycki
Jej! Cały czas myślę że to ja :(

A co myślałeś że jednemu psu Burek dali? ;-)
Ja kiedyś myślałem że moje nazwisko nie jest zbyt popularne a tu w
roddzinnej miejscowości (~30 tys. mieszkańców) z ksiązki telefonicznej
dowiedziałem się że jest 5 rodzin Zarzyckich, a z żadną nie jestem
spokrewniony.

Seweryn Habdank-Wojewódzki - 6 Sty 2006, 04:00

Witam

| To znaczy pisząc na grupę o C/C++ miałem na myśli te języki
Nie ma znaczenia jaki język,

To znaczy w metodologii nie, ale moje pierwotne pytanie dotyczyło narzędzi,
myślę, że przy wyborze narzędzia język odgrywa rolę. Może za nie długo nie,
ale na razie pewnie tak.

TDD to metodyka tworzenia aplikacji zakładająca stworzenie testów a
następnie budowanie aplikacji tak aby te testy spełniły (maksymalne
uproszczenie TDD).

Rozumiem.

Metodyka nic nie mówi o tym jak testować, natomiast ważny jest moment
powstania tychże, bo powstają wcześniej niż kod a ten manewr ma zapewnić że
pirwszoplanowym testem będzie spełnienie wymagań użytkownika (testy powstają
na bazie wymagań) a nie sprawdzenie czy aplikacja "chodzi" (bo to jest mało
ważne, jeśli potrzeby użytkownika są zaspokojone).

Jasne. Tylko, że wymagania są opisem jakościowym zagadnienia, i testy muszą być
przygotowywane na bazie specyfikacji. Potem do chodzi jakość - czy program
działa czy nie, a potem w moim przypadku, ilością jest to jakie wartości
program generuje.

Wyobraź sobie sytuację. Codziennie na drogach przejeżdża mnóstwo samochodów.
Odnotowywujemy je w systemie. Następnie wymaganiem klienta jest to aby
przewidywać jaki będzie ruch pojazdów w przyszłości np. do 1/2 godziny
naprzód.

No więc zaprzęgliśmy matematykę i mamy jakieś wyniki z wykresów widać, że
dobre, aplikacja się nie wiesza, działa on-line, potrafi się uczyć i takie
tam. Była testowana wiele razy dla różnych danych.

Wejściami są dane o ruchu drogowym i wyjście też. Więc specyfikacja jest
spełniona, nie wiesza się nie ma mem leaków itd. Wyniki z oglądu (na bazie
danych historycznych) są dobre.

Teraz mamy kolejny projekt i dla celów marketingowych dobrzeby było móc

nie napiszę, że stosowano, jak nie zastosowano. Moje pytanie jest takie jak

się sugestie, które są rozsądne, tłumacze jednak oco mi dokładnie chodzi.

Pozdrawiam.

Zbyszek Zarzycki - 6 Sty 2006, 05:16

To znaczy w metodologii nie, ale moje pierwotne pytanie dotyczyło narzędzi,
myślę, że przy wyborze narzędzia język odgrywa rolę. Może za nie długo nie,
ale na razie pewnie tak.

Takimi narzędziami są Borland Caliber lub (cholera konkurencja ;)
Mercury Test Director i dla nich język nie odgrywa roli.
Polecane przez innych narzędzia do UnitTesting mają niewiele wspólnego z
TDD. Testy modułowe są doskonałym narzędziem do sprawdzenia czy kod
działa zgodnie ze specyfikacją kodu, ale mają niewiele wspólnego ze
sprawdzeniem czy wymagania użytkownika są spełnione.

[...]
Jeśli dla wymagania nie można opisać sposobu przetestowania jego
spłnienia to znaczy że to nie jest wymaganie, tylko pobożne życzenie ;-)

Teraz mamy kolejny projekt i dla celów marketingowych dobrzeby było móc

nie napiszę, że stosowano, jak nie zastosowano. Moje pytanie jest takie jak

się sugestie, które są rozsądne, tłumacze jednak oco mi dokładnie chodzi.

Jeśli postępowanie jest zgodne z metodyką to jest ona używana, jeśli nie
to nie. W tym konkretnym przypadku jeśli aplikacja jest budowana w celu

że zastosowano TDD.

Maciej Sobczak - 6 Sty 2006, 05:39

Teraz mamy kolejny projekt i dla celów marketingowych dobrzeby było móc

gdzie klient zapytał producenta, czy jego program to hurtownia danych.
Chodziło o pewien program, który faktycznie korzystał z bazy danych, ale
z hurtownią nie miało to kompletnie nic wspólnego.
W tym wypadku, ani klient ani producent nie wiedzieli naprawdę co to
jest hurtownia danych, ale ponieważ klient pytał (dlaczego?), to
producent odpowiedział: tak, ten program jest hurtownią.
I wszyscy byli zadowoleni.

ale osobiście nie uznaje kłamstwa i w projekcie
nie napiszę, że stosowano, jak nie zastosowano

TDD to nie jest cel, tylko narzędzie. Podobnie, jak programowanie
obiektowe. Nie oczekuj od całości, że będzie zrobione w TDD, podobnie
jak nie oczekuj od całości, że będzie zrobione w OO. Można natomiast
oczekiwać, że zarówno TDD jak i OO będą wykorzystane tam (i tylko tam!),
gdzie może to sprawić, że produkt będzie lepszy. Hasło reklamowe, że
całość jest TDD (albo OO, itd.) nie musi wcale produktowi pomóc - no,
chyba że mówimy o takiej sytuacji, jak z tą hurtownią. ;)

Moje pytanie jest takie jak

Jeśli zastosowano TDD chociaż w części projektu, to napisz, że
zastosowano TDD w projekcie. Będzie to prawdą tak samo, jak w
stwierdzeniu, że w produkcji jakiegoś samochodu wykorzystano włókna
węglowe, itd.

Zbyszek Malec - 6 Sty 2006, 06:43

A co myślałeś że jednemu psu Burek dali? ;-)

Jak już się wczytam, to wiem, że ty, to nie ja. Ale na pierwszy rzut oka mi

pamiętam! I dopiero po chwili przychodzi ulga. Teraz też myślałem że sam
sobie odpowiadam ;)

Ja kiedyś myślałem że moje nazwisko nie jest zbyt popularne a tu w
roddzinnej miejscowości (~30 tys. mieszkańców) z ksiązki telefonicznej
dowiedziałem się że jest 5 rodzin Zarzyckich, a z żadną nie jestem
spokrewniony.

To tak jak u mnie. Malców w moim mieście jak psów (albo jak mrówków, zależy
skąd się pochodzi).

Pozdrawiam immiennika! :D

Bronek Kozicki - 6 Sty 2006, 06:49

| ale osobiście nie uznaje kłamstwa i w projekcie
| nie napiszę, że stosowano, jak nie zastosowano
TDD to nie jest cel, tylko narzędzie. Podobnie, jak programowanie
obiektowe. Nie oczekuj od całości, że będzie zrobione w TDD, podobnie

... dokładnie. Nie da się zastosować TDD do wszystkiego - w
szczególności nie sprawdzisz czy spełnia *zmienne* oczekiwania klienta.
Do tego stosuje się metody Agile, do których TDD dobrze pasuje - o ile
nie próbuje wychodzić za swoją działkę i przewidywać przyszłych wymagań.
Albo testować tego czego poprawności nie można zweryfikować.

Seweryn Habdank-Wojewódzki - 6 Sty 2006, 09:50

Witam

| Teraz mamy kolejny projekt i dla celów marketingowych dobrzeby było móc

gdzie klient zapytał producenta, czy jego program to hurtownia danych.
Chodziło o pewien program, który faktycznie korzystał z bazy danych, ale
z hurtownią nie miało to kompletnie nic wspólnego.
W tym wypadku, ani klient ani producent nie wiedzieli naprawdę co to
jest hurtownia danych, ale ponieważ klient pytał (dlaczego?), to
producent odpowiedział: tak, ten program jest hurtownią.
I wszyscy byli zadowoleni.

No co Ty myślisz o tej firmie? Kilka razy rozmawiałem z różnymi sprzedawcami
nt. różnych rzeczy wykorzystanych w w sofcie (chodziło o algorytmy) i jak mi
facet mówił, że wykorzystali ... (i tu przytaczał tonę magicznych
trzyliterowych skrótw). A potem na pytanie gdzie to jest użyte nie chciał lub
nie potrafił powiedzieć nic to olewałem, go. Czasami miało to wpływ na pewne
decyzje. Po prostu jak kolesie są nie wiarygodni to nie mam ochoty z kimś
takim rozmawiać. Pomyśl sobie tak przykładowo (banalny przykład). Ktoś mi
mówi, że program spełnia reżim hard real-time, a spełnia np. inteligentny soft
real-time albo częśiowo hard a częściowo soft, ale nie mówi mi gdzie jest soft
a gdzie hard, a mi zależy na hard w jakiejś części. Więc jeśli on mi nie powie
prawdy, a odkryję wadę przy okazji i już z nim nie będę rozmawiał. On zawsze
się wykręci, że przecież ja nie pytałem (nie wiem czemu dziś nie można polegać
na słowie drugiego człowieka), a opisy softu są zazwyczaj lakoniczne.

Ostatnio rozmawiałem z przedstawicielem matlaba i wypytalem go o szczegóły
penych obliczeń on mi odpowiedział dokładnie co jest a co nie jest zrobione (z
notatek na stronach matlaba to nie wynika) i wiem na co ten program stać, a
na co nie. Nie zapłacę za soft, który potem wywalę do kosza, bo czegoś nie da
się zrobić.

| ale osobiście nie uznaje kłamstwa i w projekcie
| nie napiszę, że stosowano, jak nie zastosowano
TDD to nie jest cel, tylko narzędzie.

Nie jest to cel, to jest użyty środek, tak jak to, że ktoś używa .net, czy
javy. Ale niektórzy (picusie) lubią jak im się roi od XXX (magicznych
trzyliterowych skrótów).

Nie oczekuj od całości, że będzie zrobione w TDD, podobnie
jak nie oczekuj od całości, że będzie zrobione w OO. Można natomiast
oczekiwać, że zarówno TDD jak i OO będą wykorzystane tam (i tylko tam!),
gdzie może to sprawić, że produkt będzie lepszy. Hasło reklamowe, że
całość jest TDD (albo OO, itd.) nie musi wcale produktowi pomóc - no,
chyba że mówimy o takiej sytuacji, jak z tą hurtownią. ;)

Jasne, że nie. I wcale nie musi być wszędzie. To rozumiem. Raczej miałem na
myśli sytuacje, że TDD jest pewnego rodzaju standardem. Coś jak ISO 9001 (dla
kodu programów).

Jeśli zastosowano TDD chociaż w części projektu, to napisz, że
zastosowano TDD w projekcie.

Nie, to napisze że moduł taki a taki (część kodu) przetestowano techikami TDD.

Pozdrawiam.

Seweryn Habdank-Wojewódzki - 6 Sty 2006, 09:55

Witam

| ale osobiście nie uznaje kłamstwa i w projekcie
| nie napiszę, że stosowano, jak nie zastosowano
| TDD to nie jest cel, tylko narzędzie. Podobnie, jak programowanie
| obiektowe. Nie oczekuj od całości, że będzie zrobione w TDD, podobnie
... dokładnie. Nie da się zastosować TDD do wszystkiego - w

To dobrze.

szczególności nie sprawdzisz czy spełnia *zmienne* oczekiwania klienta.

Tym lepiej, bo często wymagania klientów zmieniają się w czasie pisania kodu,
jak im coś się spodoba.

Do tego stosuje się metody Agile, do których TDD dobrze pasuje - o ile
nie próbuje wychodzić za swoją działkę i przewidywać przyszłych wymagań.

Jasne. No to mnie uspokoiłeś. To TDD nie jest, żadnym standardem, jest tylko
pewną formą podejścia do testów.

Pozdrawiam.

zbyszekz - 6 Sty 2006, 12:32

| Jeśli zastosowano TDD chociaż w części projektu, to napisz, że
| zastosowano TDD w projekcie.
Nie, to napisze że moduł taki a taki (część kodu) przetestowano techikami
TDD.

Dla nieznających się nie będzie istotne, a dla fachowców z daleka pachnie
kantem.
Nie ma technik testowania TDD, TDD to metodyka tworzenia projektu.

Seweryn Habdank-Wojewódzki - 6 Sty 2006, 15:00

Witam

Dla nieznających się nie będzie istotne, a dla fachowców z daleka pachnie
kantem.
Nie ma technik testowania TDD, TDD to metodyka tworzenia projektu.

Aha. Na sieci znalazłem coś takiego: "znajomość technik Test Driven
Development" jako wymaganie na stanowisko pracy.

Czemu TDD jest metodyką tworzenia projektu jeśli ona służy testowaniu? Nie
kapuje co ma tworzenie z testowaniem wspólnego przy takim poziomie abstrakcji
o jakim tu mówimy. Pytam bo po prostu nie wiem.

Pozdrawiam.

zbyszekz - 6 Sty 2006, 15:18

Witam

| Dla nieznających się nie będzie istotne, a dla fachowców z daleka pachnie
| kantem.
| Nie ma technik testowania TDD, TDD to metodyka tworzenia projektu.
Aha. Na sieci znalazłem coś takiego: "znajomość technik Test Driven
Development" jako wymaganie na stanowisko pracy.
Czemu TDD jest metodyką tworzenia projektu jeśli ona służy testowaniu? Nie
kapuje co ma tworzenie z testowaniem wspólnego przy takim poziomie
abstrakcji
o jakim tu mówimy. Pytam bo po prostu nie wiem.

Jak sama nazwa wskazuje Test Driven Development (Budowa kierowana testami)
TDD sluży budowie (głównie aplikacji) a testowanie jest motorem obrotu
kolejnych faz tworzenia aplikacji.
Tak więc to testowanie służy metodyce TDD a nie odwrotnie.
Technik w TDD jest więcej niż tylko testowanie, zaczyna się od wydobywania
wymagań (elicitation) a kończy na pozyskiwaniu opinii użytkownika o gotowym
produkcie.
TDD jest jedną z bardziej formalnych metodyk z rodziny Extreme Programing
(powstała z resztą wcześniej niż XP).

Marcin 'Qrczak' Kowalczyk - 6 Sty 2006, 15:35

Czemu TDD jest metodyką tworzenia projektu jeśli ona służy testowaniu?

http://en.wikipedia.org/wiki/Test-driven_development
http://www.google.com/search?q=test+driven+development

Seweryn Habdank-Wojewódzki - 6 Sty 2006, 17:01

Witam

| Czemu TDD jest metodyką tworzenia projektu jeśli ona służy testowaniu?
http://en.wikipedia.org/wiki/Test-driven_development
http://www.google.com/search?q=test+driven+development

To czytałem, ale widać słabo kapowałem o co dokładnie chodzi. Teraz już mi
powoli świta taki TQM w programowaniu.

Mam zatem jeszcze pytanie. W czym zatem tkwi problem?

Pozdrawiam.

zbyszekz - 6 Sty 2006, 17:48

To czytałem, ale widać słabo kapowałem o co dokładnie chodzi. Teraz już mi
powoli świta taki TQM w programowaniu.
Mam zatem jeszcze pytanie. W czym zatem tkwi problem?

Ty nam powiedz, to Twój problem.

Seweryn Habdank-Wojewódzki - 7 Sty 2006, 06:55

Witam

| To czytałem, ale widać słabo kapowałem o co dokładnie chodzi. Teraz już mi
| powoli świta taki TQM w programowaniu.
| Mam zatem jeszcze pytanie. W czym zatem tkwi problem?
Ty nam powiedz, to Twój problem.

A może gdzieś sa przykłady raportów z takich testów, czy w ogóle jakiś opis jak
się do tego zabrać profesjonalnie?

Pozdrawiam.

zbyszekz - 7 Sty 2006, 09:37

A może gdzieś sa przykłady raportów z takich testów, czy w ogóle jakiś
opis jak
się do tego zabrać profesjonalnie?

Czegoś Ty się uczepił tych testów?
To nie jest Devlopment Driven Test tylko odwrotnie.

Chcesz przyklad prosze bardzo:

1.3.2 Średni czas obslugi klienta musi być krószy niż 3 min.
Test:
Próba: 332 os.
Czas min.: 18 sek
Czas max: 732 sek.
Czas średni: 154 sek.
Test passed.

Spam z Borland? Konferencja Borland Developer Days 2004...
(OT) TEST
Test kompetencyjene z C/C++
Test kompilatora

riw blackdeath filmik

budowa narzB1dF3w rodnych schemat

futra tu typuj na 28 2 2003 piatek

odrobaczywienie yorka

Kolekcja tematów z for internetowych ^^ Strona Główna