2015-11-24 37 views
22

Attualmente sto studiando gli approcci di test per le applicazioni basate su Redux/React. Sono andato attraverso un'esercitazione redux sui test, ma hanno ancora domande:Test unitario di applicazioni React/Redux

  1. ha senso per testare creatori di azione semplici, che appena restituire un oggetto con type e payload campo? Per me, odora di test getter/setter in applicazioni OO.

  2. In caso di test di un'azione asincrona, è necessario verificare le azioni corrispondenti di successo e vengono inviate? Ancora una volta, con le richieste HTTP derise, sembra proprio come testare i contenitori dei mock, non il comportamento delle applicazioni.

  3. In caso di verifica della messa a fuoco nei riduttori, poiché sono responsabili delle transizioni di stato, significa un comportamento dei componenti collegati?

  4. Forse invece di testare l'intestino del redux dell'applicazione, dovrebbe essere testato più su un livello di componenti? Quali aspetti del componente dovrebbero essere testati quando? Quei test sono fragili?

Mi piacerebbe sentire una certa esperienza di persone che usano Redux/Reagire nella produzione e praticare attivamente test.

+0

2. Penso che valga la pena provare in caso di invio di più azioni come: FOO_LOADING, FOO_RECEIVED. Per verificare che siano stati spediti nell'ordine corretto con i carichi utili corretti. –

risposta

9

Risponderò a ciascuna domanda a turno, solo con diversi livelli di dettaglio corrispondenti alla mia esperienza.

tl dr: focus sul comportamento specifico di applicazione e le prove delle funzioni, lasciare che le biblioteche si preoccupano Redux dettagli di implementazione e testare le funzioni di piccole riduttore prima di essere mai utilizzato in componenti.

  1. Se si utilizza un'astrazione come redux-actions come ho fatto io inizialmente utilizzando redux, quindi non proprio. Se si restituiscono manualmente gli oggetti con le stesse proprietà ripetutamente, è sufficiente impostare un semplice caso di test che esegue il loop sui creatori di azioni esposte, li chiama con valori e controlla i tipi di oggetto restituiti. Overkill per pochi, ma diventa un controllo di sanità mentale a buon mercato per quando hai molti creatori di azioni. Es:

    for (var i = 0; i < actions.length; i++) { 
        let action = actions[i](testData); 
        expect(action).to.have.property('type'); 
        expect(action).to.have.property('payload'); 
    } 
    
  2. Una domanda confusamente formulata, ma in ogni caso, l'esperienza mi ha insegnato a cose di prova eccessivamente si occupano della rete. Casi di cover cover a causa di timeout e alcune aspettative sulla forma della risposta ai riduttori e l'ordine in cui sono stati chiamati.

  3. Sì, è necessario concentrarsi sui riduttori. Questa è la domanda più importante in quanto riguarda uno dei motivi per cui il redux ha successo. Tutto è semplice funzioni combinate in potenti e facilmente ragionate su funzioni (riduttori).

    Quindi, se avessimo:

    const reducer = combineReducers({ 
        a: reduceA, 
        b: reduceB 
    }) 
    

    Poi testare il comportamento di (reduceA e reduceB) ogni riduttore in casi di test separati. Vorresti comunque testare i risultati restituiti e le loro forme, ma cerca sempre di interrompere i riduttori sia nell'implementazione che nei test.

  4. Come prima dovresti utilizzare piccole funzioni e le loro implementazioni in fase di test prima di essere utilizzate in un framework di componenti specifico (qui presupposto react.js). Se si seguono i consigli forniti nel docs

    E 'consigliabile che solo i componenti di primo livello della tua app (come ad esempio i gestori di percorso) sono a conoscenza di Redux. I componenti sotto di loro dovrebbero essere presentativi e ricevere tutti i dati tramite oggetti di scena.

    Poi tutto quello che dovete provare è i componenti di alto livello ottenendo redux di dispatch passata in, e poi prova se i componenti semplici chiamare i gestori come onClick, o cogliere lo stato a destra, fuori del tuo negozio, ma questi dovrebbero avere solo essere semplici spie o asserzioni sulla forma e sul valore degli oggetti di scena, non proprio correlate a Redux.

1

Si può provare a utilizzare redux-actions-assertions per la prova di azioni e creatori d'azione. Permette di scrivere asserzioni leggibili su una sola riga ed evitare la fase di preparazione del punto vendita.