To pytanie ma już odpowiedź tutaj:

Obecnie jestem zaangażowany w programowanie w C # - Oto kilka podstaw: wdrażamy MVP z naszą aplikacją kliencką i mamy regułę cykliczną, która stwierdza, że żadna metoda nie powinna mieć złożoności cyklicznej większej niż 5. Prowadzi to do wielu małych prywatnych metody, które są generalnie odpowiedzialne za jedną rzecz.

Moje pytanie dotyczy testów jednostkowych klasy:

Testowanie prywatnej implementacji metodami publicznymi jest w porządku ... Nie mam problemu z implementacją tego.

Ale ... co z następującymi przypadkami:

Przykład 1 Obsługuj wynik żądania asynchronicznego odzyskiwania danych (metoda wywołania zwrotnego nie powinna być publiczna wyłącznie do celów testowych)

Przykład 2. Moduł obsługi zdarzeń, który wykonuje operację (na przykład aktualizuje tekst etykiety widoku - głupi przykład, wiem ...)

Przykład 3. Używasz frameworka innej firmy, który pozwala na rozszerzenie poprzez zastąpienie chronionych metod wirtualnych (ścieżka od metod publicznych do tych metod wirtualnych jest ogólnie traktowana jako programowanie czarnej skrzynki i będzie zawierała wszelkiego rodzaju zależności, które zapewnia framework nie chcę wiedzieć o)

Powyższe przykłady nie wydają się być wynikiem złego projektu. Nie wydają się też kandydatami do przejścia do osobnej klasy do testowania w izolacji, ponieważ takie metody stracą kontekst.

Czy ktoś ma jakieś przemyślenia na ten temat?

Cheers, Jason

EDYTOWAĆ Nie sądzę, aby moje pierwotne pytanie było wystarczająco jasne - mogę testować prywatne metody za pomocą akcesoriów i wyśmiewać połączenia / metody za pomocą TypeMock. To nie jest problem. Problem polega na testowaniu rzeczy, które nie muszą być publiczne lub nie mogą być publiczne.

Nie chcę upubliczniać kodu dla celów testowych, ponieważ może wprowadzać luki w zabezpieczeniach (publikowanie tylko interfejsu do ukrycia tej opcji nie jest możliwe, ponieważ każdy może po prostu rzutować obiekt z powrotem na swój pierwotny typ i uzyskać dostęp do różnych rzeczy Nie chciałbym ic

Kod, który jest refaktoryzowany do innej klasy do testowania, jest w porządku - ale może stracić kontekst. Zawsze uważałem, że złą praktyką jest posiadanie klas pomocniczych, które mogą zawierać pulę kodu bez określonego kontekstu - (tutaj myślę o SRP). Naprawdę nie sądzę, że to działa również w przypadku programów obsługi zdarzeń.

Cieszę się, że udowodniono mi błąd - po prostu nie jestem pewien, jak przetestować tę funkcjonalność! Zawsze myślałem, że jeśli może się zepsuć lub zmienić - przetestuj to.

Cheers, Jason