[Parseval]

Cześć,
Jak piszecie unit testy pod soft, który jest dedykowany dla innej architektury? W moim przypadku robię development na Ubuntu z x86 pod płytkę ARMową z RTOSem, problem jest taki, że nawet chcąc oddzielić logikę pod unit testy od warstwy RTOSa, to i tak potrzebuję skompilować całość. Czy problem jest głównie w mojej architekturze kodu czy jest na to jakieś sprytne obejście?

#embedded #linux #cpp #programowanie #programista15k #unittest

[LazyInitializationException]

@Parseval: Nie powinieneś tego testować unitami raczej

[dict]

to i tak potrzebuję skompilować całość

@Parseval: no tak będzie, dopóki nie będziesz miał idealnie czystego kodu, bez zależności do OS'a.
Możesz to na poziomie inkludów / preprocesora załatwiać w parze z flagami kompilacji, ale wątpie czy gra jest warta świeczki, bo wymaga sporo staranności i konsekwencji.

Powiedz sobie, że jeśli coś jest n---------e, to jest wystarczająco ok. ...no chyba że faktycznie potrzebujesz d--------o.

[zetisdead]

Czy problem jest głównie w mojej architekturze kodu czy jest na to jakieś sprytne obejście?

@Parseval: w architekturze. Nie wydzieliłeś rzeczy specyficznych dla danej platformy. Potem robisz dwie implementacje tej części linux i rtos.

[a231]

@Parseval: normalnie, funkcje realizujące logikę piszesz tak, żeby wszystkie drivery zamockowac. Tylko driverów i BSP nie da się tak otestowac. Także musisz się zastanowić bardziej nad architektura.

[Strus]

@Parseval: W architekturze. Kod powinienenś mieć napisany w taki sposób, żeby tylko najniższa warstwa zależała od systemu, a reszta była uniwersalna. Wtedy w testach to co jest "OS specific" mockujesz i jest bajka.

Plus dzięki takiej architekturze raz, że masz łatwiej przenieść kod na inny procesor/system, dwa, że możesz sobie napisać implementację tej najniższej warstwy pod Ubuntu (emulując oczywiście hardwarowe rzeczy), tym samym ułatwiając sobie cały development.

[happy3dprints]

@Parseval: nie wiem jak to zrobić w cpo, wiem jak podobne rzeczy można rozwiązać w Javie. Masz coś takiego jak testcointainers czyli możesz w dockerze postawic sobie jakiś oś z czym tam chcesz i się z tym laczyc podczas testów
I ogólnie w dockerach mozesz odpalać testy. Skoro na ci praktycznie zawsze stawia się cocker żeby odpalić testy to czemu nie robić tego na laptopie swoim?

[MamCieNaHita]

@happy3dprints: gadasz o niebie, a on o chlebie...

[zetisdead]

Czy sensownie w tym przypadku jest stworzenie jakiegoś thread poola

@Parseval: nie, powinieneś mieć tylko warstwę abstrakcji nad API do wątków, synchronizacji itp.

Nie wiem jakiego masz tam ARMa i z jakim rtosem i jaką biblioteką systemową, ale jeśli możesz użyć c++11 (lub nowszego), to masz na w nim gotowe api do wątków, które powinno ci zapewnić izolację od konkretnej implementacji.

[Parseval]

@zetisdead ARM z cortexem A7. Używam C++20, a RTOS to Xenomai. Jest to dość mocno specyficzny RTOS, który nadpisuje wszystkie POSIXowe funkcje własnymi implementacjami, z czym się długo kopałem. Może coś przeoczyłem, ale czy to API ma jakiś interfejs, który mogę sobie zaimplementować dla tego RTOSa?

[zetisdead]

@Parseval: chwila, skoro masz tam API posixowe i już go używasz to w czym jest problem? To samo api masz pod linuxem.

Może coś przeoczyłem, ale czy to API ma jakiś interfejs, który mogę sobie zaimplementować dla tego RTOSa?

Szukaj w źródłach bibliotek.

[Parseval]

@zetisdead zapomniałem o tym jednym szczególe, do wątków nie jest POSIXowe, taki potworek.

https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__alchemy__task.html

Jest możliwość, żeby było POSIX, ale akurat mam płytkę gdzie nie jest to zrobione i muszę z tym żyć.