You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 25, 2020. It is now read-only.
I love tests being generated along with the handlers with mocked responses. However I think that a BlackBox approach to the API functional testing works better for this project. The main advantage is that it allows you to swap API framework and change the internal implementation of the API and the tests will work as we would only test input output over http based on the swagger definition.
implementation Eg.
t.test('GET: /items',(tt)=>{api.get('/items').set(defaultHeaders).expect('Content-Type',/json/).expect(200).end((err,res)=>{tt.error(err,'valid respose code and content type');constresponse=res.body;constvalidate=validator(apiDef.paths['/items']['get']['responses']['200']['schema']);tt.ok(validate(response),'valid response format');// having ditched the mocked responses you can add fixtures to the db and then // tt.deepEqual(response.results, expectedResults);tt.end();});});
I love tests being generated along with the handlers with mocked responses. However I think that a BlackBox approach to the API functional testing works better for this project. The main advantage is that it allows you to swap API framework and change the internal implementation of the API and the tests will work as we would only test input output over http based on the swagger definition.
implementation Eg.