dużo interface'ów - stub'y i fake implementacje


@KwasowyProktolog10kJava: i potem #!$%@? się 6h przy 3-godzinnym tasku nad fejk implementacją do unit testów, które sprawdzają tylko jedną klaskę.

Unity niech #!$%@?ą mocki ile wlezie bo czas to pieniądz, ale po prostu lepiej zrobić dużo testów integracyjnych, które postawią jakąś bazkę embedded czy test-container.

Największy problem z fejk implementacjami do testów jest taki, że pracujemy w Scrumie, Agile. Wymagania biznesowe zmieniają się co
  • Odpowiedz
@nad__czlowiek: unit to pojęcie względne. Purysta mógł by powiedzieć, że twój test nie jest unit testem, bo zależy od standardowej klasy String a nie jakiejś abstrakcji.

Najlepiej mieć to w p*****e i pisać testy bez myślenia o tym podziale
  • Odpowiedz
Możecie podrzucić mi swojego builda gradle ze spockiem?

coś mam spartolone se:

Receiver class org.codehaus.groovy.macro.transform.MacroMethodsCache does not define or inherit an implementation of the resolved method 'abstract java.lang.String getDisablePropertyName()' of abstract class org.codehaus.groovy.transform.stc.AbstractExtensionMethodCache.


a zrobiłem najprostszy test na 2+2
#java #programowanie #spock #groovy #gradle
aczutuse - Możecie podrzucić mi swojego builda gradle ze spockiem?

coś mam spartol...

źródło: comment_16711036429bDkcle9XHBt7OeGdKHAQS.jpg

Pobierz
@alex-fortune: jeśli chodzi o języki:

C++: tu było całkiem dobrze, bo C++ ma na tyle prostacki i zły system budowania, że Bazel z automatu staję się przejściem w XXI wiek. Szybkie czasy kompilacji, trzymanie developerów za mordę (żeby nie wymyślali głupich rozwiązań) i budowanie wszystkiego ze źródeł to super zalety w porównaniu do popularnego CMake. Było dużo problemów z pierdołami typu ktoś w googlu uznał, że pliki .cpp będzie się budowało
  • Odpowiedz