Come gestire il test con le funzioni di inizializzazione che chiamano funzioni simulate?

Question

Come gestire il test con le funzioni di inizializzazione che chiamano funzioni simulate?

#1 da (2 voti)
#2 da (0 voti)

3

Sto lavorando su un progetto C incorporato in cui è presente una funzione utilizzata per inizializzare l'handle dell'oggetto contesto di un modulo (foo). Pertanto, durante il test utilizzando Ceedling ho utilizzato questa funzione di inizializzazione nella configurazione:

#include "unity.h"
#include "mock_bar.h"
#include "foo.h"

static foo_handle s = NULL;

void setUp(void)
{
    s = foo_init(&bar_assertAlert, &bar_releaseAlert);
}

Come puoi vedere la funzione foo_init() richiede due maniglie per le funzioni da un altro modulo (barra). Ciò consente a quelle funzioni di essere chiamate nel caso di un evento asincrono. Il modulo barra viene deriso da Ceedling in modo che possa testare l'utilizzo di tali funzioni in alcuni test.

Tuttavia, poiché le funzioni della barra sono prese in giro, i rapporti di setUp come test falliscono ogni volta poiché la funzione init chiama effettivamente il bar_releaseAlert per garantire che sia stato iniziale.

"Function bar_releaseAlert.  Called more times than expected."

Posso aggiungere un "ignore" al setup, come sotto, ma mi sembra sbagliato avere il codice del tipo di test in un set up o in un down. Forse questa ipotesi è sbagliata?

void setUp(void)
{
    bar_releaseAlert_Ignore();
    s = foo_init(&bar_assertAlert, &bar_releaseAlert);
}

O è questo povero disegno da parte mia? Come posso testare un modulo che utilizza una funzione fittizia in cui il setup chiama quella funzione fittizia?

tdd c mocking initialization

posta Toby 07.11.2016 - 12:52

fonte

2 risposte

0

Dichiarazione di non responsabilità: non sono affatto uno sviluppatore o tester esperto di software, né ho lavorato con il ceedling per un tempo molto lungo. Detto questo, ecco i miei pensieri al riguardo:

Se la funzione di inizializzazione non è troppo complessa per questo, puoi anche provare ad emulare il suo comportamento di base in setUp senza chiamare effettivamente nulla. L'IMO che chiama la funzione di un modulo testato in setUp ha l'ulteriore svantaggio di voler effettivamente provare questa funzione e non solo usarla. Per esempio. se chiami la funzione di inizializzazione in setUp e cambi, tutti i tuoi test potrebbero fallire a causa di questo e potrebbe essere difficile trovarne il motivo (diverse funzioni potrebbero causare diversi fallimenti).

Nei miei test ho semplicemente estratto le cose necessarie dalle funzioni di init e poi ho provato come se nulla fosse successo. Funziona così lontano.

risposta data 11.10.2018 - 10:45

fonte

Leggi altre domande sui tag tdd c mocking initialization

Modelli di costruzione e di progetto per il targeting di sapori .NET Core e .NET Framework? Le migliori pratiche per evitare i rami parziali

score 2 · Accepted Answer

Come utente di Ceedling, ho già lottato con queste idee. Idealmente, si vorrebbe evitare test diretti nelle funzioni setUp, ma a causa del modo in cui Ceedling e Cmock funzionano solo con Expect e Ignore in setUp è accettabile in quanto controlla più i mock e poi verifica in questa fase.

Una delle grandi cose di Cmock è che ti costringerà a tener conto ogni volta di una funzione beffarda anche se poi ti imbatti in situazioni come questa in cui dovrai Aspettarti o Ignorare quando potrebbe non essere il fulcro di cosa vuoi testare.

Se chiami bar_releaseAlert in qualsiasi altro posto nei tuoi test, ti consiglio di utilizzare bar_releaseAlert_Expect poiché Ignore lo ignorerà fino a quando non ti aspetti che potrebbe non essere quello che desideri.

void setUp(void)
{
    bar_releaseAlert_Expect(); //Expect instead of Ignore if used elsewhere
    s = foo_init(&bar_assertAlert, &bar_releaseAlert);
}

Un'altra opzione sta utilizzando il plugin fake_function_framework invece di cmock, che puoi controllare se sono state chiamate funzioni e quante volte è stata chiamata una funzione che può funzionare meglio per quello che stai facendo.

A titolo di approfondimento su come l'unità e il lavoro di ceeding consentano i test sia nel setUp che nell'ampli tearDown e influisce sul modo in cui pensi che Ceedling funzioni, ad esempio, tearDown non verrà chiamato se un test è ignorato .