[markaron]

Mirki, mockować zewnętrzny web service czy nie?
#programowanie #tdd

[n.....y]

@markaron: Mockować ( ͡° ͜ʖ ͡°)

[S.....k]

@markaron: a zdeplojowany na czym?

[markaron]

@Szinek: Ten web service? A nie wiem bo to zewnętrzny jest. Na 90% coś Javowego

[a.....r]

@markaron: Zależy czy test jednostkowy czy integracyjny.

[markaron]

@nienarodzony: No właśnie nie wiem :P Jeżeli zrobię mocka to będę miał pewność, że testy przejdą nawet jak serwis będzie niedostępny. Z drugiej strony jeżeli coś się zmieni w serwisie (a to jest zewnętrzny serwis) to testy tego nie wykryją. Dodam, że nie jestem fanem dzielenia testów na jednostkowe i integracyjne.

#dylematyprogramisty

[1.....p]

@markaron: ten webservice nie posiada wersjonowania api?

[markaron]

@1080p: nie
@archlinuxuser: Pytałem w kontekście czy mocki to code smell bo coraz częściej się słyszy takie głosy

[stacktrace]

Dodam, że nie jestem fanem dzielenia testów na jednostkowe i integracyjne.

@markaron: to właśnie tutaj zaczyna się Twój problem. Nie trzeba być fanem, ale dobre praktyki warto wdrażać u siebie.

Pytałem w kontekście czy mocki to code smell bo coraz częściej się słyszy takie głosy

Mógłbyś pokazać gdzie tak piszą? Bo to bardzo ciekawe.

[1.....p]

@markaron: ja osobiście doszedłem do wniosku, że mockowanie nie ma sensu. Przestałem rozróżniać testy na jednostkowe i integracyjne - liczy się dla mnie efekt końcowy tj. ile błędów wykryje/unikne dzięki testom.

[markaron]

@stacktrace:

to właśnie tutaj zaczyna się Twój problem. Nie trzeba być fanem, ale dobre praktyki warto wdrażać u siebie.

Kiedyś rozróżniałem, teraz dla mnie ważny jest wynik testów, niż sam sposób ich realizacji. Teraz testy u mnie wyglądają następująco:

- testy logiki domenowej, nie ważne czy z mockami czy bez (tutaj stosuję podejście znane z TDD)
- testy logiki aplikacji czyli implementacji przypadków użycia (tutaj BDD)

Mógłbyś pokazać gdzie tak piszą?

[a.....r]

Pytałem w kontekście czy mocki to code smell bo coraz częściej się słyszy takie głosy

@markaron: Jeśli jest ich dużo, a szczególnie gdy służą do testowania zależności zależności konkretnego obiektu, to są złe.

W ogóle są dwie szkoły TDD, oryginalna i londyńska. Oryginalna Kenta Becka opiera się głównie na testowaniu przepływu danych od wejścia do wyjścia. Londyńska (Growing Object Oriented Systems guided by tests) mocno opiera się na mockowaniu.

Wybranie konkretnego