Wpis z mikrobloga

#java #programowanie

Ma ktoś pomysł jak przetestować wyrzucanie tego wyjątku?
AirborneStatus ma 2 pola, jedno jest stringiem a drugie booleanem, nie ma opcji żeby podać złe dane - o ile nie ma błędu w oprogramowaniu, wiadomość zawsze utworzy się dobra, a wtedy też dobrze się zaszyfruje do XMLa...

Chciałabym uniknąć używania PowerMocka (obie metody są statyczne, klasy Utils...), bo słyszałam że to świadczy o złym designie... W takim razie jak przeształcić ten kod żeby był dobry i testowalny?
Myślę nad tym i myślę i nie wiem jak to wymyślić ( ͡° ͜ʖ ͡°)
Pobierz noelo_cohelo - #java #programowanie

Ma ktoś pomysł jak przetestować wyrzucanie teg...
źródło: comment_bYAK9xI0Ld38sBGft3HzKsJkt06WJSAg.jpg
  • 28
Co jeśli nie mogę tego zrobić? [wstrzykiwać w konstruktorze?] Obecnie system jest tak zbudowany że konstruktor jest dziedziczony.


@noelo_cohelo: Nie powinno to stanowić problemu, bo:

* powinnaś preferować kompozycję wobec dziedziczenia: https://en.wikipedia.org/wiki/Composition_over_inheritance => czyli jak przekombinowałaś z dziedziczeniem i utrudnia Ci to działania, to raczej należy tutaj zacząć fixowanie dizajnu
* konstruktor można nadpisać => parentowi przekazujesz co potrzebuje, sobie przypisujesz co Ty potrzebujesz
* jak konstruowanie obiektu robi się skomplikowane,
a to protected - zwiększamy widoczność metody tylko pod testy? średnio mi to wygląda


@noelo_cohelo: tak, ma to na celu "poprawienie" testowalności. Poprawienie dałem w cudzysłów, ponieważ jest to bardzo brzydki workaround. Niestety czasami trzeba robić takie rzeczy, gdy korzystamy z mechanizmów zewnętrznych.

Generalnie podpisuję się rękami i nogami pod tym co napisał @MacDada. Od siebie mogę polecić przestudiowanie podejścia TDD - po pewnym czasie, nawet nie zauważysz kiedy, podświadomie
Myślałam o tym, wtedy wybuchnie na createFlightStatusMessage i też nie będzie to JAXBException.


@noelo_cohelo: Nie robię w Javie: co ten cały JAXBException reprezentuje? Kiedy wyskakuje? Załóżmy, że createFlightStatusMessage nie waliduje jakoś message => jak powinno message wyglądać, żeby JAXBException wyskoczyło?

Swoją drogą tutaj znów wychodzi, że static statica pogania ;p Bo przecież FlightObjectUtils też nie masz jak podmienić ;)

Generalnie jak masz zamiar użyć słowa util w nazwie klasy, to raczej
spotkałeś się kiedyś w kodzie "produkcyjnym", żeby ktoś Loggery przekazywał w konstruktorze?


@nfan: Nie robię w Javie. Osobiście unikam statyka jak ognia. Zresztą, w PHP mamy standard PSR-3, który definiuje LoggerInterface => czyli właśnie standardem jest przyjmować obiekt w konstruktorze (który implementuje ten interface), a nie jakieś latanie statykami.

Statyki to rak sprzed 15–u lat => z dzisiejszą wiedzą (SOLID) i narzędziami (kontenerki zależności) nie ma powodu, żeby dalej akceptować
@MacDada Aha, w Javie to stała praktyka. Masz rację, przy DI static nie powinien się pojawiać bo wszystkie zależności są ogarnięte za nas, więc koszt ich dostarczenia jest prawie zerowy. Niestety nie zawsze da sie s****c uniknąć, ale przy pisaniu nowego kodu musimy nad tym panować :D
@nfan: Jakbym siadł teraz Javy i framework/biblioteka by mi sugerował odwołanie statyczne (np SpringLogger.getInstance().log('blah'); to bym wyodrębnił moją własną abstrakcję i ją wstrzykiwał:

interface Logger
{
    public void log(String message);
}
class SpringLoggerAdapter implements Logger
{
    public void log(String message)
    {
        SpringLogger.getInstance().log(message);
    }
}
class MyLoggerConsumer
{
    public void MyLoggerConsumer(Logger logger);
}

Zresztą, to dobra praktyka, bo robisz cieniutką warstewkę, a uniezależniasz się od frameworka (możesz podmienić sposób logowania w przyszłości
@MacDada stworznie takiej warstwy nie jest problemem. Wydaje mi się, że najgorsze jest to, że podejście static logger w klasie jest promowoane przez większość dużych bibliotek/frameworków przezco programiści propagują to w kolejnych projektach. Niestety nie żyjemy w idealnym świecie :D
@MacDada: właśnie JAXB może wyskoczyć z marshal a nie z createFlightObjectMessage. JAXB to jest błąd marshalowania - czyli konwersji automatycznie wygenerowanego beana na XML. załóżmy że jest ustawiony walidator w XmlUtils, a obiekt message nie zawiera np. wymaganego timestampa, po prostu nie został ustawiony, a jest zdefiniowany jako required w XSD (Xml Schema Definition).

Generalnie jak masz zamiar użyć słowa util w nazwie klasy, to raczej pięć razy się zastanów, bo