È consigliabile utilizzare un servizio di simulazione per testare le richieste http?

2

È meglio testare l'unità utilizzando una libreria fittizia come "nock" (nodejs) o semplicemente testare direttamente le richieste HTTP del server?

Ecco un esempio del mio test del server Express per verificare se il mio server è attivo e verificare i dati di yelp che vengono serviti dal mio server.

test.js:

describe('Express server', () => {
  let request;

  beforeEach(() => {
    request = chai.request(app);
  });
  it('It runs', (done) => {
    request.get('/').end((err, res) => {

      expect(res).to.have.status(200);

      done();
    });
  })

  it('/post serves yelp data', (done) => {


    //  let yelp = nock('localhost:8080').post('/post', mockplace)
    let mockPlace = [
      {
        name: 'Le Thai',
        coords: {
          lat: 36.168743,
          lng: -115.139866
        }
      }
    ];

    let expected = {
      name: 'Le Thai',
      img: 'https://s3-media1.fl.yelpcdn.com/bphoto/vYnAqILo37UXrNvz_5QX0Q/o.jpg',
      hours: false,
      revcount: 1425,
      rating: 4,
      price: '$$',
      location: '523 Fremont St,Las Vegas, NV 89101',
      phone: '(702) 778-0888',
      url: 'https://www.yelp.com/biz/le-thai-las-vegas?adjust_creative=euqH0_vzVDHpkWNkOrRvRg&utm_campaign=yelp_api_v3&utm_medium=api_v3_business_search&utm_source=euqH0_vzVDHpkWNkOrRvRg'
    }

    request.post('/post').set('content-type', 'application/json').send(mockPlace).end((err, res) => {

      assert.deepEqual(res.body[0], expected);
      done();
    })

  })
});

Ho provato i test in entrambi i modi descritti sopra e ho notato che l'utilizzo di un servizio di simulazione come nock riduce drasticamente il tempo di esecuzione della suite di test. Questa sarebbe l'unica ragione per usare un servizio di simulazione?

Se sto usando un servizio di simulazione, allora qual è il punto di fare i test in primo luogo?

    
posta Dream_Cap 25.02.2018 - 08:20
fonte

1 risposta

3

Dato che parliamo di unit test , la risposta probabile è sì, dovremmo prendere in giro le chiamate remote. O meglio detto, dovremmo isolare il codice sotto test da inferenze esterne . Ho detto simulato ma, in questo caso, forse, sarebbe opportuno parlare di stub .

Per farla breve, i test di unità dovrebbero essere testati per garantire il corretto comportamento di uno o più componenti specifici, al fine di acquisire confidenza nel loro comportamento. A tal fine, abbiamo bisogno che questi test siano deterministici.

Per raggiungere il di solito isoliamo i componenti in prova da inferenze esterne che potrebbero causare il fallimento del test * . Vogliamo solo dimostrare la correttezza di piccoli pezzi di codice indipendentemente dalle interazioni con altri pezzi. Questo è importante perché vogliamo essere in grado di eseguire questi test in qualsiasi momento, rapidamente e ottenere sempre il risultato previsto. In definitiva, i test unitari sono la prima difesa contro le modifiche che causano effetti collaterali inattesi (e dannosi).

Come ho detto, vogliamo che siano veloci per un paio di motivi:

  • Sono numerosi (confrontati con test di integrazione e altri)

  • Vogliamo essere in grado di eseguirli manualmente in qualsiasi momento senza erodere la nostra produttività.

  • Idealmente, i test unitari vengono eseguiti ogni volta che costruiamo il progetto. Se miriamo ad un'integrazione continua e alla consegna continua, la rapidità della fase di costruzione è importante poiché condiziona il time-to-market **.

In che modo il test contro le integrazioni reali influisce sul determinismo e rapidità ?

I servizi remoti con cui ci integriamo potrebbero cambiare o fallire in qualsiasi momento, facendo sì che i nostri test non siano più deterministici. Inoltre, le integrazioni reali potrebbero rallentare i tempi dei test, provocando un prolungamento della fase di costruzione, erodendo la produttività e potenzialmente il time-to-market .

then what is the point of doing the testing in the first place?

Il punto è testare il codice rispetto a una specifica versione del contratto. Di solito l'ultimo al momento dell'integrazione.

Tuttavia, poiché Heraclitus ha dichiarato "L'unica cosa è costante è il cambiamento" . I contratti non fanno eccezione. Possono cambiare e potrebbero farlo senza il nostro consenso. Quindi, mentre il futuro rimane sconosciuto, il presente ci impone di testare il nostro codice contro i contratti attuali senza mancare: determinismo, predittività e rapidità .

Detto questo, ciò non significa che non possiamo eseguire test con integrazioni reali. Possiamo, ma questi test non sono considerati unitari. Per ulteriori informazioni su questo argomento, consulta il link .

Ulteriori letture

* Complessivamente da quelli che non abbiamo controllo

** Potrebbero essere coinvolti costi opportunità

    
risposta data 25.02.2018 - 11:07
fonte