Unit-Testing: Problem mit static in Funktion

[StinkyWinky (Gast)]

Hallo Gemeinde

Ich habe eine C-Funktion, welche lokale static Variablen benützt, um 
z.B. den Zustand einer FSM zu speichern.
Nun möchte ich zu dieser Funktion eine Testfunktion schreiben. Dazu 
müsste ich aber die statische Variable von aussen manipulieren können.

Gibt es eine halbwegs elegante Lösung, wie man von aussen (separates 
Testmodul) an diese statische Variable gelangt?

[GoP (Gast)]

Sowas muss man nicht erst testen um zu wissen, dass es Murks ist. Das 
kann man gleich fixen.

[Neil (Gast)]

Nein, wenn Du mit "lokal" eine lokale Variable innerhalb der Funktion 
meinst.
Ja, wenn Du mit "lokal" eine lokale Variable innerhalb des C-Moduls 
meinst in dem sich deine Funktion befindet. In diesem Fall mußt Du dem 
Modul eine "set"-Funktion für diese Variable hinzufügen und via Header 
sichtbar machen.

Neil

[StinkyWinky (Gast)]

Nein, mit lokal meine ich eine static Variable innerhalb einer Funktion.
Auf die Statischen eines Modules ist der Zugriff ja kein Problem.

[Markus V. (Gast)]

Ein relativ eleganter Weg wäre, die statics in ein eigenes Modul zu 
packen, das während des Tests zur Laufzeit durch ein Mock-Modul ersetzt 
wird. Das ist in OO-Sprachen eine gängige Vorgehensweise und leicht zu 
realisieren, in C könnte das aber das ein klein wenig Hirnschmalz 
erfordern.

Gruß
Markus

[Michael R. (dj_motionx)]

So wenn das jetzt völliger Schnurz ist killt mich bitte nicht ;-)

Die statische Variable bleibt konstant an einer Stelle im Speicher. Du 
könntest also in eine externe Zeigervariable die Adresse deiner 
statischen Variable in der Funktion schreiben. Diese Adressvariable 
macht du dann mittels Header deinem Unit Test Modul sichtbar. Willst du 
deine statische Variable verändern schreibt dein Testmodul auf die 
Speicherstelle auf die der Zeiger zeigt. Das ganze macht du mittels 
#define für den "normalen" Betrieb unsichtbar.

L.g.

[Udo S. (urschmitt)]

Die Frage ist doch ob diese statische Variable Sinn macht. Man versucht 
da ja innerhalb der Funktion eine Art Gedächtnis zu implementieren.
Das ist wie bei strtok().
Die Funktion ist nicht reentrant und führt in jeglichen 
Multithreadinganwendungen zu nicht reproduzierbaren Fehlern.

Im Allgemeinen ist es oft besser statt einer static Variablen innerhalb 
einer Funktion dieser Funktion eine Adresse auf eine ausserhalb 
definierten Variable zu übergeben.
So können unterschiedliche Aufrufer (rekursiv / multithreading) auch 
ggf. unterschiedliche Versionen der Variable halten.

[Michael R. (dj_motionx)]

So hab das jetzt schnell probiert. Problem hatte ich nur dass die 
Adresse ja irgendwie initialisiert werden muss. Das hab ich mir einer 
zusätzlichen init Variable gelöst. Aber das Prinzip mit der Adresse 
funktioniert.
Hier mein Minimalcode:

#define UNIT_TEST

#ifdef UNIT_TEST
static char init;
#endif

static unsigned int *a_step;

void fsm(void);

void fsm(void) {
  static unsigned int step = 0;
#ifdef UNIT_TEST
  if (init){
    a_step=&step;
    init=0;
    return;
  }
#endif

  switch (step) {
  case 0:
    printf("Case 1\n");
    step++;
    break;
  case 1:
    printf("Case 2\n");
    step++;
    break;
  case 2:
    printf("Case 3\n");
    step = 0;
    break;
  defualt:
    break;
  }
}

void normal (void) {
  printf("Normal Operation\n");
  printf("Call 1\n");
  fsm();
  printf("Call 2\n");
  fsm();
  printf("Call 3\n");
  fsm();
}

void unitTest (void) {
#ifdef UNIT_TEST
  // call fsm first for init address
  init=1;
  fsm();
  printf("Test case 3\n");
  *a_step = 2;
  // test
  fsm();
#else
  fprintf(stderr,"Unit test not defined but function called\n");
#endif
}

[StinkyWinky (Gast)]

@Michael
Danke für das Beispiel. Ja das funktioniert so. Jetzt müsste man das nur 
noch in ein Makro packen können, damit es wenn möglich so ähnlich 
aussieht:

void fsm(void) {
  MY_SPECIAL_STATIC(unsigned int, step, 0);

  switch (step) {
  case 0:
    printf("Case 1\n");
    step++;
    break;
...

Das wäre wahrscheinlich sogar machbar.

@Markus
Das mit dem Auslagern von funktions-lokalen statischen Variablen ist mir 
nicht klar, wie das gehen soll.

@Udo
Full ACK. Bei diesem Ziel-Projekt handelt es sich um ein Embedded 
System, ohne Multi-Threading. Getestet wird allerdings auf dem PC, mit 
GCC.

[Klaus W. (mfgkw)]

Welchen Sinn hat eigentlich ein unit-Test, wenn sich die Funktion 
während des Tests anders verhält dank #define UNIT_TEST?

[Tom K. (ez81)]

Warum nicht so?

typedef struct
{
    uint8_t step;
} fsm_state;

void fsm(fsm_state* p_state)
{
   switch(p_state->step)
   ...
   ...
   ...
}

void unit_test(void)
{
   fsm_state state;
   state.step = 2;
   fsm(&state);
   ...

}

Wie Udo schon schrieb, sind static variablen für eine vernünftige 
Testbarkeit des Codes fast so tödlich wie die bösen Singletons.

[StinkyWinky (Gast)]

Natürlich macht es wenig Sinn, überall #ifdef UNIT_TEST einzustreuen. 
Aber machnchmal geht's halt nicht anders. Und wegen in paar solcher 
Situationen auf Unit-Tests zu verzichten, kann nicht die Lösung sein.

@Tom
Ich sehe da zwei Probleme:
- Teilweise habe ich Funktionen, die mehrere statische Variable haben.
- Der Aufrufer muss die Variable ja auch statisch halten. Am Schluss 
sind dann alle statischen als Modul-global zu definieren. Das will ich 
genau nicht.

Ich versuche es mal mit dem Ansatz von Michael.

Danke für Eure Meinungen.

[Unke (Gast)]

... du solltest dir aber im klaren darüber sein, dass bereits ein #ifdef 
UNIT_TEST eine Validierung deiner Funktion durch den Unit Test über den 
Haufen wirft. Aber vielleicht kommt es hier darauf ja gar nicht an...

[GoP (Gast)]

Offensichtlich geht es hier sowieso nicht darum, mehr Qualitaet zu 
erreichen, sondern nur darum den Punkt "Unit-Tests" auf der 
Anforderungsliste abzuhaken. Da ist es dann nicht wichtig, ob man mit 
Ausnahmen fuer den Unit-Test denselbigen ad absurdum fuehrt.

[Karl H. (kbuchegg)]

Trenn halt einfach deine FSM in ein eigenes Modul ab, pack es in sein 
eigenes C-File. Dann machst du deine State Variable anstatt 
funktions-static file-static und schon ist das Problem keines mehr.

static unsigned int step;

void fsm(void)
{
  switch (step) {
  case 0:
    printf("Case 1\n");
    step++;
    break;
  case 1:
    printf("Case 2\n");
    step++;
    break;
  case 2:
    printf("Case 3\n");
    step = 0;
    break;
  defualt:
    break;
  }
}

void unit_test()
{
  step = 0;
  // sonstige Vorbedingungen herstellen
  fsm();
  if( step != 1 )
    printf( "ERR001: Fehler in FSM. Zustandsübergang 0->1 nicht durchgeführt\n" );

  ...
}

Die Funktion unit_test könnte man als Ganzes noch mit einem #ifdef aus 
dem Compilevorgang ausschliessen, wenn man dem Linker nicht traut. Aber 
mehr muss es nicht sein.

Die Organisation von C-Programmen fängt auf File-Ebene an. Ein C-File 
ist ein Modul. Und das kann in sich geschlossen werden, so dass zwar 
alle Funktionen innerhalb des Moduls sich Daten(strukturen) teilen 
können, aber trotzdem ausserhalb keiner ran kann.

[Mark B. (markbrandis)]

Udo Schmitt schrieb:
> Die Frage ist doch ob diese statische Variable Sinn macht. Man versucht
> da ja innerhalb der Funktion eine Art Gedächtnis zu implementieren.
> Das ist wie bei strtok().
> Die Funktion ist nicht reentrant und führt in jeglichen
> Multithreadinganwendungen zu nicht reproduzierbaren Fehlern.

Tom K. schrieb:
> Wie Udo schon schrieb, sind static variablen für eine vernünftige
> Testbarkeit des Codes fast so tödlich wie die bösen Singletons.

Hmmmm. Also fassen wir zusammen:
1.) Globale Variablen gelten bekanntlich als "böse" und man soll sie so 
wenig verwenden wie eben möglich.
2.) static-Variablen innerhalb einer Funktion sind Euch zufolge 
ebenfalls sehr pöse.

Was aber nun, wenn ich ein Gedächtnis brauche? Da gibt es doch etliche 
Anwendungsfälle dafür, wo eben das Ergebnis einer Berechnung im 
aktuellen Durchlauf abhängig ist von früheren Berechnungen. Beispiel: 
Digitales Filter.
Wie setzt Ihr sowas um, dass es Euren hehren Ansprüchen genügt? Wilde 
Verpointerung quer über alle Module? ;-)

[Karl H. (kbuchegg)]

Mark Brandis schrieb:
> Hmmmm. Also fassen wir zusammen:
> 1.) Globale Variablen gelten bekanntlich als "böse" und man soll sie so
> wenig verwenden wie eben möglich.

richtig.
Man soll Funktionen mit Argumenten aufrufen und nicht Argumentpassing 
per Zuweisung an globle Variablen lösen.
Darum geht es nämlich in Wirklichkeit bei der Argumentation "Globale 
Variablen sind böse".
Darum und um gordnete Progammstrukturen mittels Datenkapselung, die 
durch globale Variablen komplett ausgehebelt wird.

> 2.) static-Variablen innerhalb einer Funktion sind Euch zufolge
> ebenfalls sehr pöse.

sie sind nicht böse. Nur in manchen Fällen unpraktisch. Weil es eben 
eher selten ist, dass sich eine Funktion, und nur diese eine Funktion, 
etwas von einem Aufruf zum nächsten merken muss. Spätestens wenn es für 
den Mechanismus dann einen Init() oder Reset() geben muss, fällt man 
damit auf die Schnauze oder landet bei wild zusammengewürfelten 
Funktionsargumenten.

> Was aber nun, wenn ich ein Gedächtnis brauche?

Da gibt es dann immer noch die 3. Variante:
File-Static im Sinne von 'lokal zu einem ganzen Modul'. Und das ist eine 
der sinnvolle Varianten, wie sich Module etwas funktionsübergreifend 
merken können. Neben noch anderen Mechanismen, wie zb opaque Datentypen 
(Ich gebe dem Aufrufer einen Pointer auf ein Datenpaket raus, welches 
ich zur Speicherung meiner Daten benutze, gebe ihm aber weiter keine 
Information darüber, wie dieses Datenpaket aufgebaut ist, so dass er mit 
dem Speicher nichts anfangen kann. Wann immer er etwas von mir will, 
gibt er mir den Pointer wieder und mit meiner Kentniss des Datenaufbaus 
kann ich damit arbeiten. Vulgo: Der Aufrufer kriegt von mir einen void 
Pointer auf die Daten und in der bearbeitenden Funktion wird er wieder 
zurückgecastet.)

[Klaus B. (Gast)]

StinkyWinky schrieb:
> Gibt es eine halbwegs elegante Lösung, wie man von aussen (separates
> Testmodul) an diese statische Variable gelangt?

Hallo,
ich schlage folgende simple Lösung vor:

#ifdef UNIT_TEST
#define STATIC
#else
#define STATIC static
#endif

STATIC uint32 myGlobalVar_u32;
...


Viele Grüße !

[Mark B. (markbrandis)]

Karl Heinz Buchegger schrieb:
> Neben noch anderen Mechanismen, wie zb opaque Datentypen
> (Ich gebe dem Aufrufer einen Pointer auf ein Datenpaket raus, welches
> ich zur Speicherung meiner Daten benutze, gebe ihm aber weiter keine
> Information darüber, wie dieses Datenpaket aufgebaut ist, so dass er mit
> dem Speicher nichts anfangen kann. Wann immer er etwas von mir will,
> gibt er mir den Pointer wieder und mit meiner Kentniss des Datenaufbaus
> kann ich damit arbeiten. Vulgo: Der Aufrufer kriegt von mir einen void
> Pointer auf die Daten und in der bearbeitenden Funktion wird er wieder
> zurückgecastet.)

Klingt gut. Danke für die Erläuterung :-)