dotnetomaniak.pl - Maciej Aniserowicz | Słowo na niedzielę, o dobrych i złych testach

Witaj Maniaku , Zaloguj sięlub Zarejestruj

Strona główna
Kategorie
- Architektura
  Rozwiązania na wyższym poziomie abstrakcji. Wzorce, dobre praktyki i pomysły.
- Bazy danych i XML
  MSSQL, Oracle, mySQL, PostgreSQL. ORMy i nie tylko
- Cloud
  Rozwiązania chmurowe - Azure, AWS i inne
- Daj się poznać 2016
  Artykuły w ramach konkursu Daj się poznać
- Daj się poznać 2017
  Artykuły w ramach konkursu Daj się poznać - edycja 2017
- Inne
  Pozostałe nigdzie indziej niesklasyfikowane artykuły
- Mobile development
  WP7, WindowsMobile, WindowsCE ale także inne platformy mobilne
- Narzędzia
  Przydatne narzędzia dla każdego
- Office
  Sharepoint i wszystko co związane z programowaniem na tę platformę
- Programowanie rozproszone
  Wszystko co związane z rozwojem aplikacji przystosowanych do obsługi więcej niż 1 maszyny
- Silverlight
  Rich Internet Applications od MS. Wszelkie wersje i dodatki.
- Sztuka programowania
  Przykłady ładnego kodu, wpisy o tym jak pisać kod aby był czymś więcej niż zlepkiem znaków
- Web
  Web Forms, MVC, jQuery i inne przydatne rzeczy dla każdego siedzącego w Web Development
- Windows
  WinForms, WPF, kontrolki i wszystko inne związane z programowaniem na platformę Windows
O dotNETomaniaku
Sklep z gadżetami

Maciej Aniserowicz | Słowo na niedzielę, o dobrych i złych testach

Pisać testy jednostkowe do wszystkiego? Celować w 100% unit-test-code-coverage? Stosować TDD dla każdego rodzaju kodu? Na te pytania bardzo łatwo znaleźć w internecie odpowiedź i brzmi ona: TAK. Niestety nie jest to odpowiedź prawidłowa. Czasem lepiej testu nie napisać, niż go napisać. Czasem lepiej test skasować, niż go po raz dziesiąty poprawiać po zmianie w kodzie.

Tagi: pokrycie kodu, testy, testy jednostkowe

Źródło: www.maciejaniserowicz.com

Dziel się z innymi: