Unit Testen en C, wie doet het en welk framework?

[daan.timmer]

Ik ben zelf een prominent voorstander van unit testen. Dit ben ik sinds ik een opdracht heb gedaan (gedetacheerd) bij ASML waarin het programma dat wij schreven volledig ge unit test moest worden. Dit was mijn eerste ervaring hiermee en vond het geweldig.

Echter, is python leuk, maar mijn hoofd programmeertaal is en blijft (embedded) C. En zoals de meesten weten hier is C alles behalve te vergelijken met Python en de vrijheid die je met Python hebt en daarmee de verschrikkelijke simpele mogelijkheid om te kunnen unit testen heb je alles behalve in C.

Ik ben zelf bekend met twee verschillende frameworks die ieder totaal anders werken, namelijk CppUTest en Unity//Ceedling. Ik ken CppUTest alleen van een boek dat speciaal geschreven is voor Testing Embedded C. Unity//Ceedling is tot nu toe mijn eerste keus echter. (Ceedling is een verzameling van tools geschreven in Ruby welke óók Unity gebruikt). Ik ben er tot nu toe erg blij mee. Het heeft zijn quirks. (Als je een file mocked dan heb je geen keuze om de originele functie call uit te laten voeren en zul je dus voor die tests altijd de functies moeten mocken, wat niet altijd wenselijk is).

Ik was benieuwd of er ook andere enthousiaste (Embedded) C ontwikkelaars zijn die gebruik maken van unit testen en wat hun ervaringen hiermee zijn.

[Omisys]

Wij gebruiken op het werk CUnit. Ik heb verder niet gewerkt met alternatieven voor C-unit tests dus ik kan niet echt een vergelijking maken. Naar mijn mening werkt CUnit prima.

[EddoH]

Ik heb CUnit en GoogleTest gebruikt. Beide volstaan, en komt neer op persoonlijke voorkeuren of specifieke features die je wel/niet wenst.

[BCC]

Veel bedrijven modelleren tegenwoordig toch hun embedded software in matlab en zetten het dan om naar een embedded oplossing? Op die manier kun je wiskundig bewijzen dat je software werkt en hoef je als gebruiker dus geen tests meer te schrijven. Bijzonder dat ASML het nog op de oude manier doet, maar ze zullen misschien ook wel elke instructiecycle uit een chip moeten persen

[ Voor 4% gewijzigd door BCC op 30-03-2016 09:52 ]

[Ealanrian]

Er zijn echt nog meer bedrijven die niet modelleren in Matlab. Wij werken met een combinatie van GoogleTest, CUnit en zelfgebouwde frameworks (voor integratie tests). Persoonlijk vind ik GoogleTest echt wel lekker werken.

[EddoH]

BCC schreef op woensdag 30 maart 2016 @ 09:01:
Veel bedrijven modelleren tegenwoordig hun embedded software in matlab en zetten het dan om naar een embedded oplossing. Op die manier kun je wiskundig bewijzen dat je software werkt en hoef je als gebruiker dus geen tests meer te schrijven. Bijzonder dat ASML het nog op de oude manier doet, maar ze zullen misschien ook wel elke instructiecycle uit een chip moeten persen

Heb je het niet over algoritmes die eerst in Matlab gemodelleerd en geverifiëerd worden? Software bestaat uit meer dan alleen bijvoorbeeld een regelalgoritme en ik kan mij moeilijk voorstellen hoe het modelleren in Matlab unit tests overbodig zou maken, maar wellicht loopt mijn kennis daar achter..

[BCC]

Embedded is ook niet mijn vakgebied, maar ik sprak op een congres mensen van Boeing en een treinenbouwer (waarvan de naam mij even ontschoten is) en die vertelden mij dat ze geen regel embedded meer schreven dankzij Matlab en dat dat een hele boel tests overbodig maakt. Daarom ook mijn verbazing

[farlane]

BCC schreef op woensdag 30 maart 2016 @ 09:01:
Veel bedrijven modelleren tegenwoordig hun embedded software in matlab en zetten het dan om naar een embedded oplossing. Op die manier kun je wiskundig bewijzen dat je software werkt en hoef je als gebruiker dus geen tests meer te schrijven. Bijzonder dat ASML het nog op de oude manier doet, maar ze zullen misschien ook wel elke instructiecycle uit een chip moeten persen

Dat matlab gebruikt wordt om algorithmes te verifieren geloof ik direct, dat veel bedrijven het gebruiken om hun software the verifieren geloof ik weinig van en al helemaal niet dat daardoor testen niet meer nodig zouden zijn.

[EddoH]

BCC schreef op woensdag 30 maart 2016 @ 09:41:
Embedded is ook niet mijn vakgebied, maar ik sprak op een congres mensen van Boeing en een treinenbouwer (waarvan de naam mij even ontschoten is) en die vertelden mij dat ze geen regel embedded meer schreven dankzij Matlab en dat dat een hele boel tests overbodig maakt. Daarom ook mijn verbazing

Klinkt als een gevalletje manager/pr medewerker van de afdeling algoritmes, als ik eerlijk ben.

[BCC]

Als ik google kom ik heel veel voorbeelden van "Matlab Simulink Embedded Coder" tegen en ook heel veel job postings hiervoor bij Boeing Bijvoorbeeld - http://nl.mathworks.com/v...coder-overview-61213.html Zo snel te zien moet je inderdaad nog steeds wel zelf tests schrijven, maar zitten ze wel op een niveau hoger dan de embedded C code. Sorry voor de offtopic

[ Voor 26% gewijzigd door BCC op 30-03-2016 09:54 ]

[EddoH]

BCC schreef op woensdag 30 maart 2016 @ 09:50:
Als ik google kom ik heel veel voorbeelden van "Matlab Simulink Embedded Coder" tegen en ook heel veel job postings hiervoor bij Boeing Bijvoorbeeld - http://nl.mathworks.com/v...coder-overview-61213.html Sorry voor de offtopic

Zoals gezegd, bij regelaloritmes en signaal processing is het prima voor te stellen dat de core in Matlab gemodelleerd en getest wordt, en ja daar zijn mensen voor nodig die dat doen. Echter bestaat software uit veel en veel meer dan alleen het regelagoritme. Denk alleen al aan dingen als user input, grafische weergave, div andere IO. Dit is naar mijn mening niet of minder geschikt om te modelleren op een dergelijke manier.

[BCC]

Ik denk bij ASML direct aan het aansturen van machines, dus vandaar mijn gedachtenkronkel . Bedankt voor de uitleg!

[ Voor 21% gewijzigd door BCC op 30-03-2016 10:05 ]

[Ealanrian]

De modellen bij ASML zijn een deel van de aansturing. Die bepalen bijvoorbeeld op welke snelheid en in welke richting een wafer word verplaatst tijdens de belichting. Die modellen maken dan weer gebruik van code die daadwerkelijk de hardware aansturen. (Dit is op basis van een verhaal wat ik ooit heb gehoord van engineers bij ASML die ze gehouden hebben op de uni)

[daan.timmer]

De code was niet direct op de machines van ASML. Het was een Python test omgeving die de machines moesten testen zowel via een simulator als real-time.

Ik programmeerde daar dus aan die Python test omgeving (welk zelf dus volledig ge unit test moesten worden).

In mijn huidige opdracht werk ik aan draaideuren en toegangspoortjes. Lijkt mij sterk dat Matlab ook maar iets kan betekenen in dergelijke omgevingen. Misschien bij de motorsturing, maar that's it. Alles wordt hier barebone geprogrammeerd/implementeerd.

Wat zijn de ervaringen met CUnit? Hoeveel handmatig werk komt hier bij kijken om een nieuwe test op te zetten?
Even als voorbeeld: Ceedling.
Opzetten van een nieuwe test is:
- maak een nieuw bestand aan met als prefix test_ (bijv test_Main.c)
- schrijf/vul twee functies setUp() en tearDown()
- elke test functie krijgt ook een prefix test_ (bijv test_Main_exitsAfterReceivingAnError)
- doe rake test:all
- profit

Opzetten van een mock gaat als volgt:
- in je test_XXX file include de header die je wilt mocken en prefix deze met mock_
- alle functies uit die header krijgen nu extra postfixes met bijvoorbeeld: Ignore, Expect, IgnoreAndReturn, ExpectAndReturn (en meer)
- in de test functie zelf roep je een van deze mocks aan indien nodig en Ceedling doet voor jou alle linking.
- aan het einde van elke test functie wordt er gekeken of alle Expected calls gemaakt zijn en/of dat er meer calls gemaakt zijn dan door de programmeur aangegeven.
- rake test:all
- profit

Vooral dit laatste (het mocken) van/via Ceedling vind ik zelf heel erg prettig. Vooral voor het crosscompilen en stubben/mocken van de hardware omgeving aangezien de software die wij schrijven uiteindelijk op een ARM chippie gaat draaien en niet op een normale desktop CPU.