C#: Najlepsze praktyki Debug.Print

Question

Jaka jest najlepsza praktyka dotycząca instrukcji Debug.Print?

Czy należy zaśmiecać moje metody szkoleniowe za pomocą instrukcji Debug.Print, czy też należy w ogóle unikać Debug.Print?

Jeśli dopuszczalne są oświadczenia Debug.Print, czy powinienem rozważyć użycie Trace.Print lub EventLog?

Czy wymagane są instrukcje Debug.Print w testach jednostkowych? Czy mogę ominąć oświadczenia Debug.Print dobrze napisanymi testami jednostkowymi?

Answer 1

Debug.Print jest do zaakceptowania, nie tylko dlatego, że zostaną skompilowane w kompilacjach wydań. Jednak "zaśmiecanie" twojego kodu nie brzmi szczególnie produktywnie lub jest użyteczne.

Można go dodać podczas debugowania określonego obszaru kodu. Po zidentyfikowaniu defektu można napisać test jednostkowy, aby zakryć sprawę, naprawić błąd, a następnie usunąć połączenie z numerem Debug.Print.

Czasem używam i zostawiam w bazie kodu: Debug.Assert - to jest jak wbudowany punkt przerwania, jeśli moja aplikacja nie jest w oczekiwanym stanie, co jest tylko dodatkową siatką bezpieczeństwa podczas wykonywania testów automatycznych i ręcznych .

Debug.Print nie jest konieczne w testach jednostkowych i nie należy go dodawać ze względu na testy jednostkowe.

Answer 2

W ogóle nie potrzebujesz Debug.Print z testami jednostkowymi! Punktem testów jednostkowych jest to, że automatycznie otrzymujesz wskazanie, czy test się powiódł, czy nie, nie musisz szukać odbitek do debugowania.

NUnit jest łatwą w użyciu biblioteką testów jednostkowych.

Jeśli chodzi o śledzenie lub rejestrowanie, nie musisz też zaśmiecać kodu przy użyciu odbitek do debugowania. Wypróbuj interception with Castle Windsor lub inne frameworki obsługujące AOP.

Answer 3

Nigdy nie użyłem Debug.Print ani Trace.Print. Piszę dużą liczbę testów jednostkowych. Nigdy nie odkryłem, że muszę używać obiektów Debug lub Trace z testami jednostkowymi, które piszę. Staram się jednak testować jednostkowo tak dużo, jak to tylko możliwe.