2009-05-28 14 views
6

Jestem zainteresowany wykorzystaniem narzędzia pokrycia kodu dla mojego następnego projektu .NET, ale zastanawiałem się, czy jest to konieczne dla mnie? Jestem jedynym programistą w firmie, dla której pracuję, więc czy korzystanie z NCover byłoby dla mnie korzyścią, czy może jest to tylko dla dużych zespołów korzystających z ciągłej integracji? DziękiCzy powinienem używać narzędzia Code Coverage Tool?

+0

Dzięki za odpowiedzi! Wszystko, co powiedzieliście, ma sens. Dlaczego po prostu nie pójść po to? Może mi tylko pomóc i dalej jako programista. :) – CalebHC

Odpowiedz

9

Powiedziałbym, idź za to. Analizowanie zasięgu kodu może pomóc nawet jednemu deweloperowi, może nawet bardziej niż zespołowi, ponieważ zasadniczo masz cały system na swoich barkach. Jeśli jesteś jedynym programistą, masz pełną kontrolę nad tym, jakich narzędzi używasz i jak chcesz je skonfigurować. Raz/jeśli zostanie dodanych więcej programistów, będziesz mieć wszystkie narzędzia potrzebne do tworzenia wysokiej jakości oprogramowania.

1

Caleb,

W przypadku, gdy nie wiesz, Visual Studio 2008 Team System Wydania VS2008 można zrobić pokrycia kodu dla Ciebie. Nie jest tak wszechstronny jak NCover, ale powinien być świetnym początkiem dla ciebie. Jeśli podoba ci się to, co robi i chcesz więcej dzwonków i gwizdów, to nie rozumiem, dlaczego nie. (To tylko 200 $ za klasyczną edycję, kiedy ostatnio sprawdzałem).

-Artel

1

Oczywiście należy go używać. To zawsze kolejne narzędzie, które ci pomoże. Pamiętaj jednak, że zasięg kodu nie jest najważniejszy podczas testowania kodu. Otrzymasz kilka linii kodu, które są pokryte testami, ale to nie znaczy, że twój kod jest tam odporny na błędy. Użyj ncover, aby znaleźć miejsca, które mają niewielki zasięg lub nie mają go wcale.

2

Jeśli podejmiesz próbę napisania zautomatyzowanych testów, zdecydowanie skorzystaj z narzędzia pokrycia kodu, aby zorientować się, jakie obszary kodu stanowią podstawę testu.

Sprawdzanie pokrycia kodu podczas pisania testów jest również pomocne w zapewnieniu, że testy faktycznie testują to, co według Ciebie są.

Narzut pokrycia kodu pomiarowego w porównaniu z narzutem testów pisemnych dni te są tak małe, że nie ma sensu pisać testów, a następnie nie oglądać zasięgu tych testów.

+0

Dobra rozmowa. Jeśli masz już testy jednostkowe, ignorowanie zasięgu jest dość głupie. Zauważyłem, że sprawdzanie zasięgu kodu zawsze poprawia moje testy (od kiedy dowiaduję się od razu, co jest uruchamiane i naprawiam to, co nie jest), a co za tym idzie, jakość mojego oprogramowania. Dobry zasięg nie jest srebrną kulą, ale zwiększa zaufanie do testów i pomaga skupić wysiłki testowe, unikając zbędnych testów i pominiętych narożników. –

Powiązane problemy