Mam duży zbiór narzędzi wiersza poleceń, które piszemy sami i często używamy. W tej chwili ich testowanie jest bardzo kłopotliwe, w związku z czym nie wykonujemy tak wielu testów, jak to jest konieczne.Najlepszy sposób na przetestowanie narzędzi wiersza poleceń?
Zastanawiam się, czy ktoś może zaproponować dobre techniki lub narzędzia do robienia dobrej roboty tego typu rzeczy.
Edycja: do wyjaśnienia jest to UNIX
Dzięki z góry. Tom
jest rozszerzeniem Cucumber do testowania aplikacji linii poleceń napisanych w dowolnym języku programowania.
Aby go użyć, do wykonania testów potrzebny będzie ruby, ale celem aruby jest udostępnienie biblioteki zdefiniowanych wcześniej definicji kroków, aby nie trzeba było pisać kodu ruby, aby wykonać próbny test zestaw. (. Chociaż w pewnym momencie prawdopodobnie będzie chciał napisać trochę ruby zrobić kilka niestandardowych kroków)
Widać wyrafinowany przykład badanego z Aruby tutaj narzędzia wiersza poleceń: jingweno/gh
Powinieneś być w stanie wywoływać je ze skryptu powłoki (plik wsadowy, na systemach operacyjnych MS), przekierować wyjście do pliku, a następnie przeskanować plik programowo, aby upewnić się, że ma poprawne wyjście. Nie znam struktury testowania, która automatyzuje to za Ciebie, ale samodzielne skonfigurowanie powinno być dość proste.
Tak - miałem nadzieję, że ktoś może być świadomy szkieletu lub narzędzia. Myślałem o tym, żeby samemu go powalić, ale nie byłoby to zbyt trudne. Pozdrawiam. Tomek –
Możesz to zrobić z pliku wsadowego pliku skryptowego systemu Windows.
Ale obiecuję skorzystać z harmonogramu zadań takiego jak (http://www.splinterware.com/products/wincron.htm) lub innego bezpłatnego/profesjonalnego oprogramowania.
Możesz w prosty sposób skopiować/wkleić parametry linii poleceń, które powinny się różnić, kiedy chcesz przetestować swoje oprogramowanie około 100 razy ?!
Zrobiłem trochę to (loooong czas temu hehe) używając Expect, aby sprawdzić, co się stało, co ja, hmm, oczekuje
Polecam strukturyzacji kodu Twojego narzędzie wiersza polecenia, tak że narzędzie wiersza polecenia jest klientem biblioteki funkcji i/lub klas.
Zamiast po prostu używać std :: cout do drukowania danych wyjściowych, funkcja biblioteczna powinna przyjmować referencje ostream, które domyślnie przyjmują std :: cout. Podczas testowania podaj łańcuch std :: string, aby zebrać dane wyjściowe.
Wreszcie, po prostu porównaj dane wyjściowe narzędzia z oczekiwanymi wynikami, korzystając z ulubionego systemu testowania jednostkowego.
(Przepraszam za konkretny przykład C++ ... Jestem pewien, że istnieją sposoby na robienie podobnych rzeczy również w innych językach).
Mogłabyś użyj biblioteki perl z biblioteką Test::more, która zapewnia doskonałą platformę do testowania interfejsów CLI. Chociaż został zaprojektowany przede wszystkim do testów jednostkowych, można go rozszerzyć, aby przetestować przepływy pracy użytkownika.
Niektóre z metod:
# Various ways to say "ok"
ok($got eq $expected, $test_name);
is ($got, $expected, $test_name);
isnt($got, $expected, $test_name);
# Rather than print STDERR "# here's what went wrong\n"
diag("here's what went wrong");
like ($got, qr/expected/, $test_name);
unlike($got, qr/expected/, $test_name);
cmp_ok($got, '==', $expected, $test_name);
Korzystanie Cram można napisać testy, które przypominają interaktywną sesję powłoki. Cram będzie odtąd odtwarzał polecenia z testu, porównywał dane wyjściowe z referencją i raportował różnice. Format testów jest dość elastyczny i pozwala na dopasowanie wyników za pomocą wyrażeń regularnych Perl lub symboli powitalnych w powłoce.
Bats (Bash Automated Testing System) od Sam Stephenson. Jest malutki, napisany czysto w skorupie i ma ładny zestaw funkcji.
Wcześniej sugerowano Aruba wygląda interesująco, ale w niektórych przypadkach może to być spokojny overkill chodzi o zależnościach (rubin, Ogórek)
Czy używając lub pisania/wytwarzania narzędzi wiersza polecenia? –