Dokumentacja wymaganego interfejsu na podstawie mocków

Czy istnieje coś takiego, w którymś z popularnych frameworków do mockowania (RR, mocka, flexmock)?
Tzn. chodzi mi o generowanie informacji o tym jakie metody zostały zmockowane, jakie były ich argumenty, etc.

Nie znalazłem niczego takiego, a byłoby to przydatne do śledzenia, czy API zmockowanych obiektów odpowiada API realnych implementacji.
Oczywiście od strony testowania jest to zadanie testów integracyjnych (tzn. zgodności API poszczególnych klas). Ale chodzi mi bardziej o wykorzystanie tego na etapie, w którym klasy te nie zostały jeszcze zaimplementowane oraz zagregowanego podglądu interfejsu klas kooperujących z daną klasą.

Czy sądzici, że coś takiego jest przydatne?

https://github.com/psyho/bogus o to chodzi?

Cześć Apohllo,
inżynier Giereś ma rację. Jakiś czas temu zakodowaliśmy bibliotekę do ‘bezpiecznej’ izolacji w testach unitowy.

Bezpieczna izolacja w w Bogusie to:
fakes - czyli automatycznie generowane obiekty testowe na podstawie interfejsu klasy;
safe stubbing - stutbowanie/mockowanie na obiektach testowych wymaga zgodności interfejsów co do nazwy metody i liczby argumentów

Część bardziej eksperymentalna to testy kontraktowe:

  • za każdym razem, kiedy w teście jednostkowym (powiedzmy, że dla UserAuthenticator) stubujesz/mockujesz zależność (np UserRepository), nagrywamy tę interakcję;
  • w teście jednostkowym zależności (UserRepository), możemy upewnić się ze wszystkie interakcje (w formie stubow/mockow) są przetestowane;
  • w taki sposób gwarantujemy zgodność interfejsów co do przekazywanych wartości.
    Wszystko to, własnie po to, żeby pozbyć się testów integracyjnych, sprawdzenie zgodności interfejsów w idealnym świecie powinno być możliwe w testach jednostkowych.

Jeszcze garść uwag o Bogusie, korzystamy z niego w komercyjnych projektach, ale wyłącznie z faków i bezpiecznych stubów. Składania do izolacji jest skopiowana z RR. Wszystkie funkcjonalności, są dokładnie opisane w dokumentacji. Aktualna implementacja testów kontraktowych wymaga, żeby wszystko co jest przekazywane między obiektami miało zdefiniowaną operację porównania, co do tej pory nie było prawdą w żadnym projekcie. :wink:

Co do Twojego pytania o dokumentację, Bogus jej nie generuje, ale wszystkie informacje do jej wygenerowanie są dostępne. Możemy ustawić się gdzieś na piwo w Krakowie i wymyślić jak to dopisać albo po prostu pogadać po kolejnym KRUGu :wink:

@gieres, @wrożka - dzięki, dokładnie o to mi chodził. Postaram się wpaść na następny KRUG żeby przedyskutować kwestię automatycznej dokumentacji :slight_smile: Aż dziw bierze, że nie ma więcej takich narzędzi.

EDIT

Swoją drogą - gadaliście z Avdim Grimmem o tej bibliotece? Sądze, że byłby nią zainteresowany, a znając jego siłę oddziaływania mógłby ją nieźle spopularyzować.

Do zobaczenia! :wink: Są podobne rozwiązania, ale raczej są podzbiorem tego co robi bogus. rspec-fire to bezpieczne stuby, a surrogate to biblioteke do generowania faków.

Może gdyby Avdi coś o tym napisał, byłoby łatwiej dostać się z tym tematem na konferencje, musimy w końcu się do niego odezwać. :wink: