nUnit i test konsolowego Program.Main

Jak najlepiej zapisać test nUnit głównej funkcji konsolowego programu?
Jak testuje się Program.Main ???

A czemu chcesz ją testować?

somekind napisał(a):

A czemu chcesz ją testować?

Zaciekawiło mnie jak to się robi...
...jak powinno się robić...
...albo jak to robią inni.
Sam nie wymyśliłem nic "eleganckiego" ;-)
Chodzi o takie napisanie testu, by napisać i o tym zapomnieć. By w każdej chwili można było uruchomić i sprawdzić czy nic się nie zmieniło.

Rozwiązania typu "kopia kodu" nie wchodzi w grę. Bo nie chodzi o to czy metoda działa ;-)
Tylko jak dla takiej metody pisze się(albo inni piszą) testy.
To taka ciekawostka.

Ja np. nigdy nie testowałem metody Main, nie miałem takiej potrzeby. W sumie nawet nie wyobrażam sobie testowania metody, która niczego nie zwraca.

somekind napisał(a):

W sumie nawet nie wyobrażam sobie testowania metody, która niczego nie zwraca.

Można łapać wyjątki, ale to właśnie wydaje mi się mało eleganckie w przypadku Main().
Bo trzeba specjalnie, tylko pod testy, przygotować metodę.

Podziel kod funkcji na mniejsze elementy (inne funkcje, dodatkowe obiekty) i testuj te składowe elementy. Jeśli podział na nie jest bez sensu to i testy do tego kodu IMHO są bez sensu. Aby testować trzeba mieć co testować i koniec kropka :)

...no można rozbić to na dodatkowe klasy.
Nawet z testowaniem argumentów(tych z wiersza poleceń) można sobie w ten sposób poradzić.
Pomysł ciekawy...

W sumie nawet nie wyobrażam sobie testowania metody, która niczego nie zwraca.

A co w tym takiego dziwnego?

class samochód
{
 Opona opona;
 
 [...]

 public UstawOpone(Opona opona)
 {
  this.opona = opona;
 }
}

Chociażby tak absurdalnie prosty przykład wymaga testu, gdyż to funkcja publiczna. Jak widać nic nie zwraca, a test wykonać powinno się.

TestujMAX napisał(a):

Chociażby tak absurdalnie prosty przykład wymaga testu, gdyż to funkcja publiczna. Jak widać nic nie zwraca, a test wykonać powinno się.

Napisz ten test i pokaż go nam.

Po prostu piszesz test i sprawdzasz czy przekazane wartości się zgadzają ze sobą.
Z definicji testy powinny zawsze być robione dla funkcji publicznych i chronionych. Nie ważne jak prosta jest to funkcja.

Poza tym z mojego doświadczenia wynika, że warto robić tego typu testy nawet dla banalnych funkcji rodem tej z wyżej lub też funkcji tego typu:

public void SetRGBColor<t>(t r, t g, t b)
{
 this.r = r;
 this.g = g;
 this.b = g;
}

...

Zauważyłeś, że w tej funkcji jest błąd?
Do "this.b" zapisuję zmienną "g". Tak być oczywiście nie powinno.
Przykład ten jest z życia wzięty z jednego z moich przykładów. Na całe szczęście robiłem w tym projekcie na bieżąco testy i widziałem, że w tej funkcji coś jest nie tak, gdyby nie to, że zrobiłem test funkcji prostej jak budowa cepa, przeoczyłbym banalny błąd i dziwiłbym się później czemu uzyskuję złe wartości dla składowych RGB. No bo komu by przyszło do głowy, że akurat w funkcji ustawiającej jest błąd?

Z tego też powodu rada by testować wszystko nie wzięła się z niczego. Jeśli testami nie obłożymy tego czego się da to nie mamy odpowiednio napisanych testów.

TestujMAX napisał(a):

Po prostu piszesz test i sprawdzasz czy przekazane wartości się zgadzają ze sobą.

Jak metoda testująca ma sprawdzić wartości pól prywatnych klasy?

Jeśli testami nie obłożymy tego czego się da to nie mamy odpowiednio napisanych testów.

Pokażesz ten test dla funkcji Main, czy nie?

Jak metoda testująca ma sprawdzić wartości pól prywatnych klasy?

można dodać do klasy metodę publiczną z [Conditional("DEBUG")], która je sprawdzi.

Pokażesz ten test dla funkcji Main, czy nie?

Chyba czegoś nie zrozumiałeś. Nikt tutaj poza autorem nie pisał o funkcji main, której się nie testuje (w życiu o czymś takim nie słyszałem).
To w funkcji main wywołuje się różne obiekty, i metody, które właśnie zostały wcześniej przetestowane.

Jeśli jednak z uporem maniaka chcesz testować w sposób absurdalny funkcję main to możesz ku temu napisać chociażby osobny projekt w solution explorer, który stworzy możliwość zasymulowania funkcji main.

TestujMAX napisał(a):

Jeśli jednak z uporem maniaka chcesz testować w sposób absurdalny funkcję main to możesz ku temu napisać chociażby osobny projekt w solution explorer, który stworzy możliwość zasymulowania funkcji main.

Jakbyś umiał czytać, to byś wiedział, że to nie ja mam zamiar testować Main. Za to Ty się tutaj wtryniłeś ze swoimi rewelacjami na temat tego, że ją też należy testować, odnosząc się do mojej, wyrwanej z kontekstu wypowiedzi. Toteż proszę jeszcze raz o przykład.

Podałem wyżej przykład jak można to zrobić. Jeśli tego nie rozumiesz to najzwyczajniej w świecie brak Ci jeszcze wiedzy w tym temacie i po prostu dalsza dyskusja nie ma sensu. Musisz się jeszcze doszkolić w tej tematyce.

Przeniosłem, niech programiści innych języków też się nauczą testować dzięki użytkownikowi @TestujMAX.

TestujMAX napisał(a):

Nikt tutaj poza autorem nie pisał o funkcji main, której się nie testuje (w życiu o czymś takim nie słyszałem).
To w funkcji main wywołuje się różne obiekty, i metody, które właśnie zostały wcześniej przetestowane.

Jeśli jednak z uporem maniaka chcesz testować w sposób absurdalny funkcję main to możesz ku temu napisać chociażby osobny projekt w solution explorer, który stworzy możliwość zasymulowania funkcji main.

Sam pisałeś wcześniej:
"Poza tym z mojego doświadczenia wynika, że warto robić tego typu testy nawet dla banalnych funkcji rodem tej z wyżej lub też funkcji tego typu:"
Skoro tak to czemu nie main? Zbyt banalna? Nie banalna?
W main też można zrobić literówki (takie jak w Twoim przykładzie)

Pytałem o sposoby testowania.
Jeśli ktoś ma jeszcze jakieś pomysły proszę się podzielić. ;-)