EF4 - możliwe fałszywe ObjectContext do testowania jednostkowego?

Czy można to zrobić bez użycia Islatora typu TypeMock? Znalazłem kilka sugestii w Internecie, takich jak przekazywanie tylko metadanych ciągu połączenia, jednak nic, co spotkałem poza TypeMock wydaje się naprawdę pozwalać na pozorowany ObjectContext, który może zostać wstrzyknięty do usług testowania jednostkowego. Czy wpłacam $$ za TypeMocka, czy są alternatywy? Czy nikt nie zdołał stworzyć niczego podobnego do TypeMocka, który jest open source?EF4 - możliwe fałszywe ObjectContext do testowania jednostkowego?

Źródło

2010-04-24 Steve Macdonald

Jedna z sugestii, którą widziałem, to złamanie reguł ponownego testowania względem bazy danych. Facet powiedział, że używa CreateDatabase(), aby utworzyć "symulację" instancji db na bieżąco. Generalnie chcę tego uniknąć, ponieważ złamaliśmy tę zasadę na wcześniejszym projekcie i nie wyszło tak dobrze. Było OK do około 600 testów, ale na końcu z> 2000 testów było całkowicie bezużyteczne dla prawdziwego TDD i przeprowadziliśmy testy w "trybie wsadowym" od czasu do czasu (trwało 5 minut lub dłużej, aby je uruchomić). –

Jestem jednostką testującą EF4 w łatwy sposób bez szyderstwa. To, co zrobiłem, to stworzenie interfejsu repozytorium z wykorzystaniem kodu z http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/ jako podstawy, po czym utworzyłem klasę InMemoryRepository<T>, która używała interfejsu IRepository. Następnie zamieniłem IObjectSet<T> wewnątrz klasy List<T> i odpowiednio zmieniłem metody pobierania.

Tak więc, jeśli chcesz wykonać test jednostkowy, przekazuj dane do InMemoryRepository, a nie do DataRepository.

Źródło

2010-05-21 17:57:32 KallDrexx

-1 Linq2Objects zachowuje się inaczej niż Linq2Entities. Testy mogą przejść na listę , ale nie powiodą się po przetworzeniu na SQL przez EF. –

Nie można tego przekazać bez dostępu do bazy danych, więc nie jestem pewien, o co ci chodzi. Szyderstwo nie oznacza, że Twój Linq2Entities zawsze będzie ważny i będzie działał prawidłowo. – KallDrexx

Zawijaj zapytania i testuj je w oparciu o prawdziwą bazę danych. Następnie wyśmiewaj ich, testując logikę biznesową. Dlatego każde zapytanie jest elementem do ponownego wykorzystania, o którym wiesz, że fakt zadziała. Twoja logika biznesowa jest testowana bez potrzeby posiadania bazy danych, która jest w oczekiwanym stanie. –

Zawiń obiekt ObjectContext w klasie proxy. Następnie wstrzyknij to do swoich klas.

Źródło

2010-04-24 04:05:48 mxmissile

Tak, próbowałem tego, i jest to możliwe - jednak wszystkie te podejścia korzystające z serwerów proxy mają swoje własne ograniczenia. Linq działa inaczej na jedną rzecz (Linq do obiektów jest używany, w przeciwieństwie do Linq do podmiotów). –

PRAWDA, ale oczekiwanie, że testy jednostek wykryją różnice w różnych implementacjach Linq, wydaje się nieco za burtą w przypadku testów jednostkowych. Że więcej na arenie testów integracyjnych nie sądzisz? – SamuelWarren

Umieść swoje zapytanie Linq2Entity za interfejsem, przetestuj urządzenie w izolacji względem prawdziwej bazy danych.

Testy zapisu dla logiki biznesowej z mockami dla interfejsów zapytań. Nie pozwól, by Linq zakradł się do twojej logiki biznesowej!

Nie używaj RepositoryPattern!

Źródło

2010-11-17 22:23:58

Nie sądzę repozytorium wzór jest jedyną odpowiedzią na pytanie (unika się problemu, na pewno)

Lubiłem tę odpowiedź - Myślę, że bardziej odpowiedni do wprowadzenia testów z istniejącym kodzie Creating Interface for ObjectContext

Źródło

2012-07-10 00:04:23 kenno

EF4 - możliwe fałszywe ObjectContext do testowania jednostkowego?

Odpowiedz

Powiązane problemy