problem z cvs-em

[bob]

Jacek Konieczny wrote:

> On Sat, Jul 14, 2001 at 01:26:25PM +0200, bob wrote:
>
>> sic! właśnie podałeś procedure testową dla pakietu cvs
>> teraz wystarczy , żeby z każdym pakietem była składowana taka 
>> procedura i żeby pakiet musiał ja pomyślnie przejść zanim trafi z 
>> test na ftp.
>>
> Na początku nie spodobało mi się to co napisałeś. Jeśli to miałby
> ręcznie robić każdy developer PLD, to ja chyba bym se darował robienie
> pakietów. Ale po chwili zastanowienia.... dochodzę do wniosku, że należy
> zrobić po prostu nowy moduł w CVS: regtest, gdzie będą umieszczane
> skrypty robiące testy regresyjne pakietów. Wszystkiego nie da się tak
> przetestować, ale wiele owszem.


zgadza sie: recznie jest niewykonalne

>
> Pod taki test musiałoby być przygotowane odpowiednie środowisko (np.
> przez nadrzędny skrypt "tester") znaczy się np. katalog roboczy, na
> którym będzie mógł test pracować.
>
> Dla cvs taki skrypt robiłby to co napisałem, a na końcu porównywał
> wyniki z oczekiwanymi (po np. ostatecznym cvs release).
>
> Dla takiego apacha można by to zrobić, prze uruchomienie go z
> uproszczonym configiem, na jakimś dziwnym porcie i próby ściągnięcia
> wget-em indeksu, pliku, może jakiegoś CGI i sprawdzenia czy jest OK.
>
> Dla wszelkich interpreterów/kompilatorów test sprawdzałby działanie
> programiku w danym języku.
>
> Dla ssh stawiałby serwer na dziwnym porcie (jeśli w ogóle jest możliwe
> odpalanie sshd nie z roota) i próbował się zalogować (dla interaktywnego
> logowania przydatny byłby expect).
>
> itd. itp.
>
> Tylko trzeba pamiętać że to i tak nigdzy wszystkiego nie przetestuje i
> mogą sie pojawiać błędne pakiety --- tego nigdy nie unikniemy i nie ma
> co zawsze doszukiwać się winnych.
>
mi przymajmniej nie chodzi o szukanie winnych, tylko o poprawę jakości. 
i jest rzeczą oczywistą, że tymi metodami nie wykryje się wszystkich 
błędów (zwłaszcza w bardziej rozbudowanych pakietach), ale jest to 
metoda w miarę automatycznej weryfikacji sporej części pakietów. IMHO 
pozwoli to na wykrycie i usunięcie sporej ilości "oczywistych"' , a 
denerwujących błędów.

Do tego dochodzi jeszcze jedna sprawa: jeśli jakiś bład przejdzie przez 
sito to poza poprawą pakietu powinno się szukać sposobu poprawienia 
skryptu weryfikującego.

pozostaje nadzieja , że skrypty weryfikujące będą proste lub bardzo 
standardowe bo jeśli ktoś zrobiłby błąd w skrypcie weryfikującym to.... 
ech.. ktoś mógłby się trochę zdenerwować

>
> Jeszcze kwestia techniczna. Wygląda na to że teki test raczej nie będzie
> jednym plikiem. Na pewno część wspólnych funkcji można wydzielić
> (przygotowanie katalogu, porównanie wyniku, wygenerowanie raportu), ale
> i tak taki test będzie się składał z kilku plików (np. skrypt testujący,
> programik wzorcowy i wzorcowy wynik). I nie wiem, czy lepiej robić
> osobne katalogi dla każdego testu, czy po prostu pliki typu: cvs.test,
> cvs.input, cvs.output.
>
> Co o tym myślicie?
>
pozdrawiam