-
Notifications
You must be signed in to change notification settings - Fork 20
Should we deprecate this module (and or rebuild it)? #53
Comments
+1 for deprecating this module. I think the test data builders are useful on their own, so I'd like to keep them - either in this module or in a standalone one. |
@ritch yes I think deprecating this would be advisable. It is a good start, but as people start developing more advanced applications it actually becomes a hinderance. I would suggest a new repository of "testing recipes" which would be a series of tips or examples on how one could test an app. At the same time this was something that really attracted me to Loopback. This lowered the bar on implementing tests and meant I could start my app with tests in place. However after using this I would now have preferred to use Chai HTTP since time is limited and this repo doesn't seem to make the cut. |
An idea: perhaps we can write a supertest/superagent wrapper instead of mocha helpers? var request;
beforeEach(function() { request = supertest(app); });
describe('as authenticated user', function() {
beforeEach(function(done) {
createUser.then(loginUser).then(function(token) {
request.set('Authorization', token.id);
done();
});
});
it('should allow GET /items', function(done) {
request.get('/items').expect(200).end(done);
});
// etc.
}); |
Nice, I didn't know about Chai HTTP. I especially like the promise support, AFAIK superagent/supertest do not support promises yet. |
@ritch what is the current outlook for this module? Will it continue to be maintained? Just asking since we are looking for a solid way to test our backend/API in a current project, and this repo if definetly on the list. |
@csvan after using this I would suggest exploring chai extensions. This was a good launchpad but we've had to make a number of hacks to keep it afloat for our infrastructure. Save yourself the pain and use widely maintained tools. |
@jrschumacher thanks for the headsup, we are leaning towards that conclusion as well. For anyone interested, a strong candidate which we are evaluating right now is frisbyjs (http://frisbyjs.com/), which is developed on top of Jasmine exclusively for testing REST APIs. We are very impressed with it so far. |
Has a decision been made yet? This module seemed to be working for us before we started doing anything with ACL's but since we have started setting up ACL's I am starting to see some real pain. @csvan I had looked at using frisby before trying this module but feel that supertest would be better suited? As this project appeared to be a wrapper around supertest I thought it was worth a shot but I think I might just use supertest on it's own and see how I get on. |
Tim, we settled for Supertest and it is working great so far. I am not On Sun, 15 Nov 2015 23:32 Tim Perry [email protected] wrote:
Christopher Svanefalk Web: http://www.csvanefalk.com |
@csvan would you mind putting a gist together on how you used supertest? |
Context
It seems like several people have started using this module. I original authored this to scratch my own itch:
https://github.com/strongloop/loopback/blob/master/test/access-control.integration.js
I had a ton of access control tests to write. Typically we just write a utility method in a test file or in a supports.js or util file somewhere to reduce the redundancy of test setup. The issue with the access control tests was that even
it()
anddescribe()
were becoming somewhat repetitive.This Module
Enter this testing module, it was initally written within loopback and specifically that file linked above. It reduced the definition of access control tests from 5-10 lines each to 1 liners.
The issues
beforeEach
is essentially hard coded into the helpersQuestion
Should we deprecate this module? We have several pull requests that we might as well land, but probably should discourage new contributions and instead willing devs should spend effort in a better direction (eg. mocha agnostic test utils).
The text was updated successfully, but these errors were encountered: