Automatyczne unit testy i message box
Seweryn Habdank-Wojewódzki
Pewnie temat byl juz walcowany, ale jakos nie moge znalezc odpowiedzi.
Mam popisane unit testy, kiedy uruchamiam je na serwerze i pojawia sie
blad w postaci
"unexpected exception" pojawia sie message box i czeka na klikniecie
OK.
To jest katastrofa, bo skad niby mam wiedziec co sie tam dzieje.
Czy ktos wie jak przekierowac wszelakie windowsiane bledy ma konsole,
albo jak automatycznie klikac "OK" z logiem dot. bledu?
Albo cokolwiek co potrafi uruchomic unit test i zgarnac bledy?
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewodzki
\/\/
Professionalism in programming - www.accu.org
Seweryn Habdank-Wojewódzki
Odpowiedz jest "prosta":
My Computer -> properties -> Advanced -> Error Reporting -> Disable
error reporting
Mateusz Loskot
news:840b8857-d405-446d...@k4g2000yqb.googlegroups.com...
> Witam,
>
> Odpowiedz jest "prosta":
>
> My Computer -> properties -> Advanced -> Error Reporting -> Disable
> error reporting
Uzyj Boost Test
Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
Krzysiek Kowaliczek
> Mam popisane unit testy, kiedy uruchamiam je na serwerze i pojawia sie
> blad w postaci
> "unexpected exception" pojawia sie message box i czeka na klikniecie
> OK.
> To jest katastrofa, bo skad niby mam wiedziec co sie tam dzieje.
Polecam podpiąć własną funkcję obsługi wyjątków:
http://msdn.microsoft.com/en-us/library/5z4bw5h5(VS.80).aspx
i wypisać stos do loga np. używając:
http://svn.pld-linux.org/cgi-bin/viewsvn/backtracexx/
Pozdrawiam
KK
Bronek Kozicki
> Witam,
>
> Pewnie temat byl juz walcowany, ale jakos nie moge znalezc odpowiedzi.
>
> Mam popisane unit testy, kiedy uruchamiam je na serwerze i pojawia sie
> blad w postaci
> "unexpected exception" pojawia sie message box i czeka na klikniecie
> OK.
> To jest katastrofa, bo skad niby mam wiedziec co sie tam dzieje.
>
> Czy ktos wie jak przekierowac wszelakie windowsiane bledy ma konsole,
> albo jak automatycznie klikac "OK" z logiem dot. bledu?
>
> Albo cokolwiek co potrafi uruchomic unit test i zgarnac bledy?
Seweryn, napisałem kilka lat temu poprawkę do bjam (do testów regresji
boost) która wypatrywała wszystkich takich dialogów i je "likwidowała"
zwyczajnie wysyłając WM_CLOSE. O ile pamiętam nie została przyjęta do
trunk ale jak chcesz to wypatrzę ten kawałek kodu, może to spróbujesz u
siebie uruchomić w jakiejś własnej usłudze czy innym programie.
Ale to jest "rozpaczliwe" działanie a nie rozwiązanie, bo dostęp do
okienek wyświetlanych w innych sesji itd to bardzo kłopotliwa kwestia
pod Windows. Nie pamiętam czy udało mi się to rozwiązać skutecznie.
B.
Maciej Wawrzynczuk
> Witam,
>
> Pewnie temat byl juz walcowany, ale jakos nie moge znalezc odpowiedzi.
>
> Mam popisane unit testy, kiedy uruchamiam je na serwerze i pojawia sie
> blad w postaci
> "unexpected exception" pojawia sie message box i czeka na klikniecie OK.
> To jest katastrofa, bo skad niby mam wiedziec co sie tam dzieje.
>
> Czy ktos wie jak przekierowac wszelakie windowsiane bledy ma konsole,
> albo jak automatycznie klikac "OK" z logiem dot. bledu?
>
> Albo cokolwiek co potrafi uruchomic unit test i zgarnac bledy?
Jak robisz te testy? Ja używam cppunit. Tamtejsze asserty wyłapują
niespodziewane wyjątki. Pare razy mi to tyłek ocaliło.
Darek
wrote:
> Witam,
>
> Pewnie temat byl juz walcowany, ale jakos nie moge znalezc odpowiedzi.
>
> Mam popisane unit testy, kiedy uruchamiam je na serwerze i pojawia sie
> blad w postaci
> "unexpected exception" pojawia sie message box i czeka na klikniecie
> OK.
> To jest katastrofa, bo skad niby mam wiedziec co sie tam dzieje.
>
> Czy ktos wie jak przekierowac wszelakie windowsiane bledy ma konsole,
> albo jak automatycznie klikac "OK" z logiem dot. bledu?
>
> Albo cokolwiek co potrafi uruchomic unit test i zgarnac bledy?
Mysle, ze Twoje wymagania spełnia CPPUnit.
Pozdrawiam
Darek Ostolski
Seweryn Habdank-Wojewódzki
> Uzyj Boost Test
No wlasnie to jest kiepska sprawa.
W unit testach napisanych z boostem jak dostaje jakis
magiczny "unhandled exception" to pojawia mi sie message box,
i tak sie sklada, ze musze kliknac button.
Problem teoretycznie jest prosty boost nie lapie wyjatkow,
ktore naruszaja ochrone pamieci przy "odwijaniu" destruktorow
obiektow statycznych. W zasadzie chyba boost juz wtedy nie
istnieje, ale jakies obiekty statyczne owszem moga.
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewódzki
Seweryn Habdank-Wojewódzki
> Seweryn, napisałem kilka lat temu poprawkę do bjam (do testów regresji
> boost) która wypatrywała wszystkich takich dialogów i je "likwidowała"
> zwyczajnie wysyłając WM_CLOSE. O ile pamiętam nie została przyjęta do
> trunk ale jak chcesz to wypatrzę ten kawałek kodu, może to spróbujesz u
> siebie uruchomić w jakiejś własnej usłudze czy innym programie.
>
> Ale to jest "rozpaczliwe" działanie a nie rozwiązanie, bo dostęp do
> okienek wyświetlanych w innych sesji itd to bardzo kłopotliwa kwestia
> pod Windows. Nie pamiętam czy udało mi się to rozwiązać skutecznie.
No wlasnie. Samo zamkniecie jest troche kiepskie, bo nic nie bede
wiedzial.
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewódzki
Seweryn Habdank-Wojewódzki
> Jak robisz te testy? Ja używam cppunit. Tamtejsze asserty wyłapują
> niespodziewane wyjątki. Pare razy mi to tyłek ocaliło.
Boost Unit Test framework. Klopot polega na tym, ze IMHO zaden
frameworek
nie pomoze na problem message box, bo jesli wyjatek leci z destruktora
wolanego na koncu programu juz poza main() to jak go zlapac?
To jest raczej kwestia jakichs ustawien w systemie, aby wyjatki
konwertowal
NIE na message box. Ale coz Windows to nie jest system stworzony z
mysla
o developerach :-).
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewódzki
Mateusz Loskot
> No wlasnie to jest kiepska sprawa.
> W unit testach napisanych z boostem jak dostaje jakis
> magiczny "unhandled exception" to pojawia mi sie message box,
> i tak sie sklada, ze musze kliknac button.
> [...]
i wlasnie dlatego UTF bazuje na execution monitor z Boost.Test
aby rozwiazac takie problemu:
#include <boost/test/included/prg_exec_monitor.hpp>
#include <stdexcept>
struct T
{
~T() { throw std::runtime_error("dead but still kicking"); }
};
int cpp_main(int, char*[])
{
T t;
return 0;
}
.\test.exe
**** exception(205): std::runtime_error: dead but still kicking
******** errors detected; see standard output for details ********
Seweryn Habdank-Wojewódzki
> Ale to jest "rozpaczliwe" działanie a nie rozwiązanie, bo dostęp do
> okienek wyświetlanych w innych sesji itd to bardzo kłopotliwa kwestia
> pod Windows. Nie pamiętam czy udało mi się to rozwiązać skutecznie.
Rozpaczliwe rozwiazanie:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Windows\ErrorMode
0 - All messages are visible (default value).
1 - Only system messages are invisible. An example of this type of
message is: "Virtual Memory Minimum Too Low."
2 - All messages are invisible. An example of this type of message is:
"Unable to Locate Component" shown when application can't load DLL
statically linked to it.
To jest bez konwersyjne ignorowanie bledow.
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewódzki
Seweryn Habdank-Wojewódzki
> i wlasnie dlatego UTF bazuje na execution monitor z Boost.Test
> aby rozwiazac takie problemu:
Jak sie prg_exec_monitor sklada z normalnymi unit testami w boost?
Nie mam np. funkcji cpp_main(), bo main() jest generowany, przez
makra w auto_test.
> #include <boost/test/included/prg_exec_monitor.hpp>
> #include <stdexcept>
> struct T
> {
> ~T() { throw std::runtime_error("dead but still kicking"); }};
>
> int cpp_main(int, char*[])
> {
> T t;
> return 0;
>
> }
Tak jak pisalem przypadek mam trudniejszy.
// code starts here
T t;
int cpp_main(int, char*[])
{
return 0;
}
cpp_main() nie ma kontroli nad t.
Zagadnienie w praktyce rozbija sie, o to
ze mam third party logger, ktory jest
singletonem i w pewnych dziwnych
okolicznosciach (tylko w trybie debug
i nie zawsze) w destruktorze wykonuje
jakies wygibasy, ktore sie zle koncza.
Klopot polega nie na tym, aby ten logger
poprawic - to jest fakt trywialny.
Jednak ogolnie takie cos jest paskudne
- zamiana jakichs windowsianych okienek
na rozsadne logi.
Mateusz Loskot
Witam,
> > i wlasnie dlatego UTF bazuje na execution monitor z Boost.Test
> > aby rozwiazac takie problemu:
>
> Jak sie prg_exec_monitor sklada z normalnymi unit testami w boost?
> Nie mam np. funkcji cpp_main(), bo main() jest generowany, przez
> makra w auto_test.
UTF bazuje na monitorze.
> Tak jak pisalem przypadek mam trudniejszy.
>
> // code starts here
>
> T t;
>
> int cpp_main(int, char*[])
> {
> return 0;
> }
>
> cpp_main() nie ma kontroli nad t.
Fakt, tu jest problem. Potrzebny jest support po stronie CRT
zas exec monitor nie wstrzykuje sie nigdzie w te rejony, AFAIK.