Strategia tworzenia interfejsów implementacji biblioteki innej firmy?

Question

Chciałbym napisać testy jednostkowe dla niektórych z moich zajęć. Niektóre z moich klas zależą od biblioteki innej firmy, która używa systemu plików i nie ma interfejsów do fałszywek.

Chciałbym kpić z klasy, aby uniknąć zależności od systemu plików, ponieważ mój kod dotyczy tylko wyników tego kodu.

Jaka jest najlepsza strategia, której można użyć do wyśmiewania konkretnych klas biblioteki bez modyfikowania biblioteki początkowej?

Myślę, że mogę utworzyć obiekt opakowujący, który implementuje interfejs i zawiera obiekt biblioteki początkowej. Jednak chcę się upewnić, że nie ma lepszego sposobu, zanim zacznę tę ścieżkę.

Czy narzędzie takie jak TypeMock byłoby w tym przypadku bardziej odpowiednie niż Moq?

Answer 1

Tło:

O ile nie jest to stabilne biblioteki/ramy jak .NET, wolę mojego kodu oddzielenie od niego. To znaczy, lubię sprawić, by biblioteka była zależna od mojego systemu, a nie od niego.

Edytuj, przerysuj: Możesz uznać bibliotekę, w której używasz "stabilny". Ponieważ jednak wchodzi on w interakcje z "zewnętrznym" systemem (systemem plików), prawdopodobnie nadal chciałbym oddzielić mój system od niego.

Aby to zrobić, tworzę adapter/opakowanie dla biblioteki. Interfejs ma metody, które mój system chce mieć w bibliotece, a nie te, które biblioteka zapewnia. Interfejs korzysta z typów, które mój system posiada, a nie z biblioteki. Adapter dokonuje niezbędnych konwersji.

Robię to, czy chcę udawać/poćwiczyć/sfałszować bibliotekę, czy nie, ponieważ zapewnia ona dobry rozdział obaw, a także chroni mój system przed zmianami w bibliotece.

odpowiedzi na pytanie:

Gdy adapter/owijki jest tam łatwo jest udawać w swoich badaniach. Jako bonus, ponieważ adapter używa języka systemu, łatwiej będzie pisać testy, które są łatwe do odczytania i zrozumienia.

Niezależnie od tego, czy korzystasz z fałszywej ramy, czy też piszesz własne podróbki, adaptery to kwestia gustu.