[Adaslaw]

Spock jest najlepszym frameworkiem do pisania testów dla języków JVM (Java, Scala, etc.).

Spock zjada JUnit i Mockito na śniadanie.

#programowanie #java #scala #kotlin #groovy

[Zelber]

@Adaslaw:
1.) Dlaczego?
2.) Jak się ma do Androida?

[Ostrzewtlumie]

@Adaslaw: w swoim projekcie uzywam i calkiem fajnie te testy wychodza ze springiem.

[zajety_login]

@Adaslaw: Tę Scalę to wywal, bo w niej Spocka akurat używa się bardzo rzadko. Zamiast tego jest ScalaTest lub Specs2, które potrafią to samo co Spock, ale robią to w statycznie typowany sposób.

[Adaslaw]

Jak się ma do Androida?

@Zelber: Androida?
Android to system operacyjny, a ja tu mówię o językach programowania i frameworkach do testowania.

[Adaslaw]

Dlaczego?

@Zelber:
Trywialne mockowanie.
Nie tylko mocki, ale również stuby i spy.
Konstrukcja "where:" bardzo ułatwiająca pisanie testów. Konstrukcja bardzo zgrabna, zwinna i zwięzła (np. w przeciwieństwie, kiedy chciałoby się to zrobić w JUnit).

[krasnoludkolo]

@Adaslaw gubi się czasem z kotlinem :(

[wqdqweff]

> Spock zjada JUnit i Mockito na śniadanie.

> sugerowanie, że to są alternatywy

@Adaslaw:

[Adaslaw]

Zamiast tego jest ScalaTest lub Specs2, które potrafią to samo co Spock, ale robią to w statycznie typowany sposób.

@zajety_login:
OK, OK.
Tych dwóch (ScalaTest i Specs2) nie znam, ale zgaduję, że skoro są statycznie typowane, to podobnie jak statycznie typowany JUnit, nigdy nie będą tak zwinne jak frameworki oparte na językach dynamicznie typowanych (np. Spock).

[Adaslaw]

gubi się czasem z kotlinem :(

@krasnoludkolo:
Hmmm...
To dziwne, skoro:
Kotlin is designed with Java Interoperability in mind.

[Zelber]

@Adaslaw:

Androida? Android to system operacyjny, a ja tu mówię o językach programowania i frameworkach do testowania.

To kodu pisanego na androida już się nie testuje? ( ͡° ͜ʖ ͡°)
Pytanie o to czy/jak działają Instrumentation tests wykorzystujące androidowe zależności jest tutaj kluczowym pytaniem.

[krasnoludkolo]

@Adaslaw dziwnie czy nie dziwne, mówię jak w praktyce jest :p

[Adaslaw]

Pytanie o to czy/jak działają Instrumentation tests wykorzystujące androidowe zależności jest tutaj kluczowym pytaniem.

@Zelber: Nie piszę na Androida dlatego Ci nie odpowiem :(
Może ktoś inny coś w tym temacie dopisze.

[zajety_login]

@Adaslaw: Różnica między ScalaTest/Specs2 a JUnit jest ogromna. To że jedno i drugie jest statycznie typowane, to chyba jedyna wspólna cecha ;)

[Adaslaw]

Różnica między ScalaTest/Specs2 a JUnit jest ogromna.

@zajety_login:
Bardziej interesowałoby mnie wykazanie, że ScalaTest/Specs2 potraf się zbliżyć do zwinności Spocka :)
JUnit nie za bardzo mnie interesuję skoro jest Spock.

[zajety_login]

@Adaslaw: Zdefiniuj zwinność :P Pokaż jakiś przykład czy coś.

[Adaslaw]

@zajety_login:

Np zwięzłe i czytelne "where:" - przykład pierwszy z brzegu:
http://spockframework.org/spock/docs/1.3/all_in_one.html#data-tables

[PoteznyMagWody]

@Adaslaw: to zaleta groovego a nie Spocka. Druga sprawa to właśnie groovy jest głównym przeciw dla Spocka, dynamiczne typowanie potrafi zgubic, utrzymywanie w projekcie dwóch różnych języków też potrafi być problematyczne. U mnie w pracy już jest zakaz dodawania nowych testów w groovym właśnie dlatego że owszem napisanie testów w nim jest prostsze, natomiast utrzymanie już nie. Najprostszy przykład: Część testów potrafi niewysypac się przy kompilacji po zmianie typu. A testy

[Adaslaw]

to zaleta groovego a nie Spocka.

@PoteznyMagWody:
Po części prawda. Ale nie do końca.
Spock to DSL ponad Groovim.

Część testów potrafi niewysypac się przy kompilacji po zmianie typu.

@PoteznyMagWody:
Jeśli faktycznie chcemy, aby zmiany typów były wyłapywane w fazie kompilacji testów grooviowych, to przecież (w ty newralgicznych fragmentach) można wymusić tym w Groovim (na etapie deklaracji zmiennej / pola).
Sam tak czasami robię, ale z innego powodu. W moim

[Krever]

Nikt piszący z własnej woli w scali nie napisze z własnej woli ani pół linijki grooviego (z małym wyjątkiem dla jenkinsa i prostych skryptów). Once you go typed you never go back.