@airdong: Nie mam czasu tego dzisiaj przeglądać, ale daję Ci plusa. Za to że Ci się chce i za to, że dzielisz się tym co czytasz z resztą mireczków. Dla takich ludzi jak Ty, wiele osób zaniechuje usunięcia konta.
  • Odpowiedz
@Variv:
No i przy cenie jaką zaproponuję prawdopodobnie AMD za wersję 8GB to będzie dobra alternatywa dla ludzi, którzy mają +- 1300 zł na kartę graficzną.
  • Odpowiedz
@rogal_king: Jak byś latał na maksymalnej widoczności (te 32 chunki, piszemy oczywiście o wersjach aktualnych) i obserwował cały czas dokładnie grę, to i tak byłoby widać co jakiś czas laga, albo spadek fps, albo bez spadku widocznego, za to nagle coś się cofnie, coś stanie w miejscu :D
Powoli to poprawiają, ale dalej to widać, no polecam też zmienić javowe GC, to trochę pomaga, bo oni używają jakiegoś przestarzałego. Od
  • Odpowiedz
@shin0bi69: Zależy jaki mają proces. Normalnie powinien ktoś to jeszcze sprawdzić lingwistycznie, a potem jeszcze testowanie sprawdza. Ale jak deadline napiera to różnie bywa. ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@aso824: w unit testach nie ma nic trudnego o ile trzymasz się podstawowych zasad obiektowości. Jak masz klasę która spełnia zasadę SRP to nie ma nic trudnego w napisaniu do niej testów, z drugiej strony, jak masz problem z przetestowaniem danej klasy to może być objaw tego, że jest ona po prostu źle napisana i wypadałoby przemyśleć jej refactoring.
  • Odpowiedz
@aso824: Najpierw zrozumiec. Te wszystkie frameworki opieraja sie na prostej zasadzie. Test sklada sie z wywolan Twoich funkcji opatrzonych assertami, np: assert(4 == twojafunkcjasumujaca(2, 2)). Testy to po prostu funkcje z takimi assertami sprawdzajacymi czy output jest taki jakiego sie spodziewales. Oczywiscie frameworki do UT dodaja mase utilsow, np. nie musisz pisac swojego maina, ktory wywola testy, masz wiecej funkcji sprawdzajacych niz prosty assert (np. equals, less then,
  • Odpowiedz