2011-07-23 32 views
5

Aby ograniczyć powielanie kodu, chciałbym programowo generować testy jednostkowe z różnych źródeł. Jednym z prostych sposobów, w jaki mogłem wymyślić, było wygenerowanie całej grupy delegatów z metody, która analizuje niektóre informacje o konfiguracji i oznacza wszystkich delegatów z atrybutem [TestMethod], które są następnie uruchamiane przez środowisko testowe Visual Studio.Przekształcanie delegatów C# w testy jednostkowe

Moją motywacją jest wykorzystanie jak największej liczby urządzeń do raportowania testów wizualnych, ponieważ mogłem napisać własną warstwę raportowania do testów za pomocą niektórych obiektów do refleksji C#, ale raczej nie. Moje rozwiązanie wydaje się dość eleganckie i proste, ale nie mogę uzyskać testu testowego Visual Studio, aby zrozumieć, co dokładnie próbuję zrobić, więc czy ktoś wie, jak zrobić to, co chciałbym?

+0

myślę, że najlepiej jest, aby wszystkie dane istotne dla badanej jednostki w pliku test jest zdefiniowane w - czy nie obawiasz się, że może to przesłonić cel testów? –

+0

Informacje konfiguracyjne będą tuż obok testów, więc nie będzie trudno prześledzić, co robią testy. – davidk01

+0

Czy można to osiągnąć za pomocą atrybutu [TestCase] ​​(http://www.nunit.org/index.php?p=testCase&r=2.5.9)? –

Odpowiedz

1

Możesz rozważyć wydanie Pex (i prawdopodobnie Moles dla starszego kodu) od Microsoft Research. Pex to projekt badawczy, który automatycznie generuje testy jednostkowe z wysokim zakresem kodu i rzekomo wybiera interesujące dane wejściowe i wyjściowe do testów. Chyba tam jest inteligencja. :)

Nie użyłem go osobiście, ale słyszałem od niektórych kolegów, że Pex i Moles są całkiem interesujący i pomogli im. Może warto zobaczyć.

Mam nadzieję, że to pomoże!

1

Myślę, że jeśli rzeczywiście chcesz generować testy, najlepiej byłoby, gdybyś wygenerował testy, używając czegoś takiego jak T4 templates. Innymi słowy, użyj generowania kodu i stwórz testowe urządzenia i metody, tak abyś je uruchamiał tak jak każdy inny przypadek testowy.

0

Przykro mi, jeśli to nie odpowiada dokładnie na twoje pytanie, ale uważam, że automatyczne generowanie testów jednostkowych jest złym sposobem rozwiązania tego problemu.
Testy jednostkowe są skutecznym sposobem na uniknięcie regresji i dostarczenie dokumentacji dotyczącej sposobu użycia kodu. Kiedy automatycznie generujesz swoje testy, dostajesz kilka testów, ale jeśli się nie uda, nie wiesz, czy istnieje prawdziwy błąd, a kończysz z wieloma błędnymi testami, że nie masz pojęcia, dlaczego zawodzą lub jak je wykonać. przechodzić. Na koniec prawdopodobnie usuniesz wszystkie testy - ponieważ "nie działają".

Mimo, że - wypróbować Armadillo z Typemock - jest to narzędzie, które pisze testy zgodnie z działaniami użytkownika

+0

Wszyscy ciągle poruszają ten punkt, ale nie ma to żadnego sensu. Cały proces testowania polega na wyeliminowaniu błędów i dostarczeniu dokumentacji oraz generowaniu testów z plików konfiguracyjnych, które jasno pokazują, jakie powinny być wejścia i wyjścia. Nikt nie mrugnie okiem, gdy narzędzia odwzorowujące odwzorowania ORM są używane do automatycznego generowania rusztowań dla dostępu do bazy danych, ale wszyscy wciąż płaczą z powodu generowania przypadków testowych z różnych plików konfiguracyjnych. – davidk01

+0

To nie jest dokładnie to samo - czy używasz ORM jako dokumentacji. testy bez logiki za nimi są poprawnymi "testami dymu", które mogą, ale nie muszą być dobre dla twojego projektu, ale nie zastępuj staroświeckich ręcznie pisanych testów jednostkowych, które faktycznie testują logikę, a nie tylko ustaw -> ustaw -> pobierz –